-PDCLib - Public Domain C Library
-================================
-
-License
--------
-
-Permission is granted to use, modify, and / or redistribute at will.
-
-This includes removing authorship notices, re-use of code parts in
-other software (with or without giving credit), and / or creating a
-commercial product based on it.
-
-This software is provided as-is. Use it at your own risk. There is
-no warranty whatsoever, neither expressed nor implied, and by using
-this software you accept that the author(s) shall not be held liable
-for any loss of data, loss of service, or other damages, be they
-incidential or consequential. Your only option other than accepting
-this is not to use the software at all.
-
-A case for Public Domain
-------------------------
-
-There was a time when you could just post a piece of code to usenet
-and say, "I give it away for free; perhaps it's useful for you."
-
-Then came the lawyers.
-
-There are building blocks in software engineering that are so basic
-that everyone should have free access to them without having to
-employ a complete legal department for advice. They should be FREE.
-Available for free, free of licensing implications, free of attached
-propaganda, free of everything but their useful self.
-
-Today, even the term "free" has to be defined by several paragraphs
-of legal blah-blah.
-
-Sick and tired of it, the author brought you this piece of software
-under a "license" that should not be neccessary in the first place:
-"Free" should have been enough.
-
-What is it
-----------
-
-This is a C Standard Library. Nothing more, nothing less. No POSIX
-or other extensions, just what's defined in ISO/IEC 9899.
-
-(Well, this is what it will be when the 1.0 release comes out. See
-the "Development Status" section to see what's implemented so far.)
-
-Internals
----------
-
-As a namespace convention, everything (files, typedefs, functions,
-macros) not defined in ISO/IEC 9899 is prefixed with _PDCLIB_*.
-As identifiers starting with '_' and a capital letter are reserved
-for the implementation, and the chances of you compiler using an
-identifier in the _PDCLIB_* range are slim, any strictly conforming
-application should work with PDCLib.
-
-PDCLib consists of several parts:
-
-1) standard headers;
-2) implementation files for standard functions;
-3) internal header files keeping complex stuff out of the standard
- headers;
-4) the central, platform-specific file _PDCLIB_config.h;
-5) optimization overlay implementation files (optional).
-
-The standard headers only contain what they are defined to contain.
-Where additional logic or macro magic is necessary, that is deferred
-to the internal files. This has been done so that the headers are
-actually educational as to what they provide (as opposed to how the
-library does it).
-
-There is a seperate implementation file for every function defined
-by the standard, named {function}.c. Not only does this avoid linking
-in huge amounts of unused code when you use but a single function,
-it also allows the optimization overlay to work (see below).
-
-Then there are internal header files, which contain all the "black
-magic" and "code fu" that were kept out of the standard headers. You
-should not have to touch them if you want to adapt PDCLib to a new
-platform. If you do, note that the PDCLib author would consider it
-a serious design flaw, and would be happy to fix it in the next PDCLib
-release. Any adaption work should be covered by the config header
-(and, possibly, the optimization overlay).
-
-For adapting PDCLib to a new platform (the trinity of CPU, operating
-system, and compiler), open _PDCLIB_config.h in your favourite text
-editor, have a look at the comments, and modify it as appropriate for
-your platform. That should be all that is actually required for such
-an adaption (see previous paragraph).
-
-Of course, your platform might provide more efficient replacements
-for the generic implementations offered by PDCLib. The math functions
-are an especially "juicy" target for optimization - while PDCLib does
-provide generic implementations for each of them, there are usually
-FPU opcodes that do the same job, only orders of magnitude faster. For
-this, you might want to create an "optimization overlay" for PDCLib.
-
-Optimization Overlay
---------------------
-
-The idea is to provide a generic implementation that is useable even
-on platforms the author never heard of - for example, the OS and/or
-compiler *you* just wrote and now need a C library for. That is
-actually what PDCLib was written for: To provide a C library for
-compiler and OS builders that do not want the usual baggage of POSIX
-and GNU extensions, licensing considerations etc. etc.
-
-Thus, PDCLib provides generic implementations. They do work, and do
-so correctly, but they are not very efficient when compared to hand-
-crafted assembler or compiler build-ins. So the author wanted to
-provide a means to modify PDCLib to run more efficiently on a given
-platform, without cluttering the main branch with tons of #ifdef
-statements and "featureset defines" that grow stale quickly.
-
-The solution is the "optimization overlay". Every function has its
-own implementation file, and _PDCLIB_config.h should be the only
-header that must be modified. So, a platform-specific overlay is
-copied over the main PDCLib branch - replacing _PDCLIB_config.h and
-any number of implementation files - to create a PDCLib adapted /
-optimized for the platform in question. That overlay could be part
-of the PDCLib source tree (for established platforms where maintainers
-won't bother with PDCLib), or part of that platform's source tree
-(for under-development platforms PDCLib maintainers won't bother with).
-
-So, to use PDCLib on your given platform, you unpack PDCLib (as you
-obviously have done already since you are reading this), and copy
-the overlay for your platform over the PDCLib source tree structure.
-
-Development Status
-------------------
-
-v0.1 - 2004-12-12
-Freestanding-only C99 implementation without any overlay, and missing
-the INTN_C() / UINTN_C() macros. <float.h> still has the enquire.c
-values hardcoded into it; not sure whether to include enquire.c in the
-package, to leave <float.h> to the overlay, or devise some parameterized
-macro magic as for <limits.h> / <stdint.h>. Not thoroughly tested, but
-I had to make the 0.1 release sometime so why not now.
-
-v0.2 - 2005-01-11
-Adds implementations for <string.h> (excluding strerror()), INTN_C() /
-UINTN_C() macros, and some improvements in the internal headers.
-Test drivers still missing, but added warnings about that.
-
-v0.3 - unreleased
-Should contain at least one overlay for GCC / x86, and implementations
-for parts of <stdlib.h>. Some test drivers.
-
+PDCLib - Public Domain C Library\r
+================================\r
+\r
+License\r
+-------\r
+\r
+Written in 2003-2012 by Martin "Solar" Baute,\r
+ 2012- by Owen Shepherd\r
+\r
+To the extent possible under law, the author(s) have dedicated all copyright \r
+and related and neighboring rights to this software to the public domain \r
+worldwide. This software is distributed without any warranty.\r
+\r
+You should have received a copy of the CC0 Public Domain Dedication along with \r
+this software. If not, see <http://creativecommons.org/publicdomain/zero/1.0/>.\r
+\r
+NOTE: Some configuration options may include components under non-public domain\r
+ conditions. In particular, selecting ptmalloc3 as the malloc \r
+ implementation will cause the incorporation of elements under the BSD \r
+ license.\r
+\r
+What is it\r
+----------\r
+\r
+This is a C Standard Library - what's defined in ISO/IEC 9899 "Information \r
+technology — Programming languages — C" or extensions to the above defined in\r
+ISO/IEC 14882 "Information technology — Programming languages — C++". A few \r
+extensions may optionally be provided.\r
+\r
+Terms for extensions\r
+--------------------\r
+Extensions are permitted where their inclusion is reasonable, they are widely\r
+used, in keeping with the spirit of the standard, and do not convey \r
+additional requirements upon the target system, and do not needlessly duplicate\r
+functionality already contained within the standard.\r
+\r
+As an example: strdup is in, because (a) it can be implemented entirely in \r
+terms of existing standard C functions and (b) is very widely used. Something\r
+like open, write or close would not be considered, because it implies POSIXy \r
+assumptions.\r
+\r
+Internals\r
+---------\r
+\r
+As a namespace convention, everything (files, typedefs, functions,\r
+macros) not defined in ISO/IEC 9899 is prefixed with _PDCLIB.\r
+The standard defines any identifiers starting with '_' and a capital\r
+letter as reserved for the implementation, and since the chances of\r
+your compiler using an identifier in the _PDCLIB range are slim,\r
+any strictly conforming application should work with this library.\r
+\r
+PDCLib consists of several parts:\r
+\r
+1) standard headers;\r
+2) implementation files for standard functions;\r
+3) internal header files keeping complex stuff out of the standard\r
+ headers;\r
+4) the central, platform-specific file _PDCLIB_config.h;\r
+5) platform-specific implementation files;\r
+\r
+The standard headers (in ./includes/) only contain what they are\r
+defined to contain. Where additional logic or macro magic is\r
+necessary, that is deferred to the internal files. This has been done\r
+so that the headers are actually educational as to what they provide\r
+(as opposed to how the library does it).\r
+\r
+There is a seperate implementation file (in ./function/{header}/) for\r
+every function defined by the standard, named {function}.c. Not only\r
+does this avoid linking in huge amounts of unused code when you use\r
+but a single function, it also allows the optimization overlay to work\r
+(see below).\r
+\r
+(The directory ./functions/_PDCLIB/ contains internal and helper\r
+functions that are not part of the standard.)\r
+\r
+Then there are internal header files (in ./internal/), which contain\r
+all the "black magic" and "code fu" that was kept out of the standard\r
+headers. You should not have to touch them if you want to adapt PDCLib\r
+to a new platform. Note that, if you *do* have to touch them, I would\r
+consider it a serious design flaw, and would be happy to fix it in the\r
+next PDCLib release. Any adaption work should be covered by the steps\r
+detailed below.\r
+\r
+For adapting PDCLib to a new platform (the trinity of CPU, operating\r
+system, and compiler), make a copy of ./platform/example/ named\r
+./platform/{your_platform}/, and modify the files of your copy to suit\r
+the constraints of your platform. When you are done, copy the contents\r
+of your platform directory over the source directory structure\r
+of PDCLib (or link them into the appropriate places). That should be\r
+all that is actually required to make PDCLib work for your platform.\r
+\r
+Future directions\r
+-----------------\r
+Obviously, full C89, C99 and C11 conformance; and full support for the \r
+applicable portions of C++98, C++03 and C++11.\r
+\r
+Support for "optimization overlays." These would allow efficient \r
+implementations of certain functions on individual platforms, for example \r
+memcpy, strcpy and memset. This requires further work to only compile in one\r
+version of a given function.\r
+\r
+Development Status\r
+------------------\r
+\r
+v0.1 - 2004-12-12\r
+Freestanding-only C99 implementation without any overlay, and missing\r
+the INTN_C() / UINTN_C() macros. <float.h> still has the enquire.c\r
+values hardcoded into it; not sure whether to include enquire.c in the\r
+package, to leave <float.h> to the overlay, or devise some parameterized\r
+macro magic as for <limits.h> / <stdint.h>. Not thoroughly tested, but\r
+I had to make the 0.1 release sometime so why not now.\r
+\r
+v0.2 - 2005-01-12\r
+Adds implementations for <string.h> (excluding strerror()), INTN_C() /\r
+UINTN_C() macros, and some improvements in the internal headers.\r
+Test drivers still missing, but added warnings about that.\r
+\r
+v0.3 - 2005-11-21\r
+Adds test drivers, fixes some bugs in <string.h>.\r
+\r
+v0.4 - 2005-02-06\r
+Implementations for parts of <stdlib.h>. Still missing are the floating\r
+point conversions, and the wide-/multibyte-character functions.\r
+\r
+v0.4.1 - 2006-11-16\r
+With v0.5 (<stdio.h>) taking longer than expected, v0.4.1 was set up as\r
+a backport of bugfixes in the current development code.\r
+- #1 realloc( NULL, size ) fails (fixed)\r
+- #2 stdlib.h - insufficient documentation (fixed)\r
+- #4 Misspelled name in credits (fixed)\r
+- #5 malloc() splits off too-small nodes (fixed)\r
+- #6 qsort() stack overflow (fixed)\r
+- #7 malloc() bug in list handling (fixed)\r
+- #8 strncmp() does not terminate at '\0' (fixed)\r
+- #9 stdint.h dysfunctional (fixed)\r
+- #10 NULL redefinition warnings (fixed)\r
+\r
+v0.5 - 2010-12-22\r
+Implementations for <inttypes.h>, <errno.h>, most parts of <stdio.h>,\r
+and strerror() from <string.h>.\r
+Still no locale / wide-char support. Enabled all GCC compiler warnings I\r
+could find, and fixed everything that threw a warning. (You see this,\r
+maintainers of Open Source software? No warnings whatsoever. Stop telling\r
+me it cannot be done.) Fixed all known bugs in the v0.4 release.\r
+\r
+Near Future\r
+-----------\r
+Current development directions are:\r
+\r
+Implement portions of the C11 standard that have a direct impact on the way \r
+that PDCLib itself is built. For example, in order to support multithreading,\r
+PDCLib needs a threading abstraction; therefore, C11's thread library is being\r
+implemented to provide the backing for this (as there is no purpose in \r
+implementing two abstractions)\r
+\r
+Cleanup portions of <stdio.h>, particularly the backend. _PDCLIB_fillbuffer and\r
+_PDCLIB_flushbuffer in particular do not feel 'well' factored and need to know\r
+too much about FILE's internals. \r
+\r
+Modularize the library somewhat. This can already be seen with components under \r
+"opt/". This structure is preliminary; it will likely change as the process \r
+continues.
\ No newline at end of file
projects / pdclib / blobdiff