-$Id$
-
PDCLib - Public Domain C Library
================================
License
-------
-Permission is granted to use, modify, and / or redistribute at will.
+PDCLib is distributed unter the Creative Commons CC0 License. You
+should have received a copy of the full legal text of this license
+as part of this distribution (COPYING.CC0). It is also available at
+
+https://creativecommons.org/publicdomain/zero/1.0/legalcode
-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.
+The following is a human-readable summary of that license.
-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
-incidental or consequential. Your only option other than accepting
-this is not to use the software at all.
+ No Copyright
-A case for Public Domain
-------------------------
+The person who associated a work with this deed has dedicated the
+work to the public domain by waiving all of his or her rights to
+the work worldwide under copyright law, including all related and
+neighboring rights, to the extent allowed by law.
-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."
+You can copy, modify, distribute and perform the work, even for
+commercial purposes, all without asking permission. See Other
+Information below.
-Then came the lawyers.
+ Other Information
-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.
+In no way are the patent or trademark rights of any person affected
+by CC0, nor are the rights that other persons may have in the work
+or in how the work is used, such as publicity or privacy rights.
-Today, even the term "free" has to be defined by several paragraphs
-of legal blah-blah.
+Unless expressly stated otherwise, the person who associated a work
+with this deed makes no warranties about the work, and disclaims
+liability for all uses of the work, to the fullest extent permitted
+by applicable law.
-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.
+When using or citing the work, you should not imply endorsement by
+the author or the affirmer.
What is it
----------
---------
As a namespace convention, everything (files, typedefs, functions,
-macros) not defined in ISO/IEC 9899 is prefixed with _PDCLIB_*.
+macros) not defined in ISO/IEC 9899 is prefixed with _PDCLIB.
The standard defines any identifiers starting with '_' and a capital
letter as reserved for the implementation, and since the chances of
-your compiler using an identifier in the _PDCLIB_* range are slim,
-any strictly conforming application should work with PDCLib.
+your compiler using an identifier in the _PDCLIB range are slim,
+any strictly conforming application should work with this library.
PDCLib consists of several parts:
Then there are internal header files (in ./internal/), which contain
all the "black magic" and "code fu" that was 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* have to touch them, 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 steps detailed below.
+to a new platform. Note that, if you *do* have to touch them, I 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 steps
+detailed below.
For adapting PDCLib to a new platform (the trinity of CPU, operating
-system, and compiler), make a copy of the ./platform/example/ directory
-(named after your target platform), and modify the files of your copy
-to suit the constraints of your platform. When you are done, copy the
-contents of your platform directory over the source directory structure
+system, and compiler), make a copy of ./platform/example/ named
+./platform/{your_platform}/, and modify the files of your copy to suit
+the constraints of your platform. When you are done, copy the contents
+of your platform directory over the source directory structure
of PDCLib (or link them into the appropriate places). That should be
all that is actually required to make PDCLib work for your platform.
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
+The basic idea of PDCLib is to provide a generic implementation that
+is useable even on platforms I have 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.
+crafted assembler or compiler build-ins. So I 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, which makes it possible to replace them
Implementations for parts of <stdlib.h>. Still missing are the floating
point conversions, and the wide-/multibyte-character functions.
-v0.5 - unreleased
-Implementations for parts of <stdio.h>. Still no locale / wide-char
-support. Enabled all GCC compiler warnings I could find, and fixed
-everything that threw a warning. (You see this, maintainers of Open
-Source software? No warnings whatsoever. Stop telling me it cannot
-be done.) Fixed all known bugs in the v0.4 release.
+v0.4.1 - 2006-11-16
+With v0.5 (<stdio.h>) taking longer than expected, v0.4.1 was set up as
+a backport of bugfixes in the current development code.
+- #1 realloc( NULL, size ) fails (fixed)
+- #2 stdlib.h - insufficient documentation (fixed)
+- #4 Misspelled name in credits (fixed)
+- #5 malloc() splits off too-small nodes (fixed)
+- #6 qsort() stack overflow (fixed)
+- #7 malloc() bug in list handling (fixed)
+- #8 strncmp() does not terminate at '\0' (fixed)
+- #9 stdint.h dysfunctional (fixed)
+- #10 NULL redefinition warnings (fixed)
+
+v0.5 - 2010-12-22
+Implementations for <inttypes.h>, <errno.h>, most parts of <stdio.h>,
+and strerror() from <string.h>.
+Still no locale / wide-char support. Enabled all GCC compiler warnings I
+could find, and fixed everything that threw a warning. (You see this,
+maintainers of Open Source software? No warnings whatsoever. Stop telling
+me it cannot be done.) Fixed all known bugs in the v0.4 release.
+
+
+A WORD ON THE v0.5 RELEASE
+==========================
+
+The v0.5 release is not well-tested. There are several things in it done
+in a way that I would never label "release quality". Some things are not
+even in the *structure* I would like them to be. An example for this is
+the current handling of errno values: It needlessly introduces dependency
+on PDCLib (because I use non-standard values), and the values are placed
+in the wrong header (_PDCLIB_int.h instead of _PDCLIB_glue.h where they
+would be more appropriate).
+
+But at some point during the development toward the v0.5 release, I found
+that my current PDCLib work schedule simply does not allow me to wait
+until every piece of <stdio.h> is as I would like it to be. It would
+probably take another year or two, and my patience is UP.
+
+I want this released, and I want to think about something else but
+<stdio.h> for some time.
+
+So, expect significant change to how stdio is done in upcoming releases.
+Everything *WILL* be stable by the time v1.0 comes around, but until then
+you will have to accept that I can only deliver "hobby quality" for now.
projects / pdclib / blobdiff