-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
+Extensions are permitted only if they pass the following tests:\r
+\r
+Pre-existing wide usage\r
+ On most systems, the system C library must maintain its application binary\r
+ interface for long periods of time (potentially eternity). Existing wide \r
+ usage demonstrates utility\r
+\r
+In keeping with the spirit of the standard\r
+ The extension should respect the design, intentions and conventions of the C\r
+ standard, and feel like a natural extension to the offered capability. \r
+\r
+Not system dependent\r
+ The extension should not add any additional dependencies on the underlying \r
+ system\r
+\r
+Non-duplicative\r
+ Extensions should not duplicate functionality already provided by the \r
+ standard\r
+\r
+Disabled by default\r
+ PDCLib will always default to a "strictly conforming" mode exposing only\r
+ functionality offered by the version of the standard specified by the\r
+ __STDC_VERSION__, __STDC__ or __cplusplus macro; extensions will only be \r
+ exposed when requested.\r
+\r
+Additionally, extra consideration will be given to extensions which are \r
+difficult or impossible to implement without access to internal structures of \r
+the C library.\r
+\r
+Conrete Examples:\r
+\r
+strndup\r
+ **Included.** strndup is easily defined in terms of existing standard \r
+ functions, follows the standard's naming conventions, is in wide usage, and\r
+ does not duplicate features already provided.\r
+\r
+posix_memalign\r
+ **Rejected.** Has existing wide usage, is not system dependent (can be \r
+ implemented, albeit inefficiently, on top of malloc), but naming is not \r
+ consistent with the naming used by the standard (posix_ prefix) and \r
+ duplicates functionality provided by the C11 standard\r
+\r
+open, close, read, write, ...\r
+ **Rejected.** Widely used, but duplicates functionality provided by the \r
+ standard (FILE objects set to be unbuffered), and not able to implement full\r
+ semantics (e.g. in relation to POSIX fork and other functionality from the \r
+ same defining standard) in a platform-neutral way\r
+\r
+strl*\r
+ **Rejected.** Used somewhat widely, in keeping with the standard, not system\r
+ dependent, but duplicative of functionality provided by (optional) Annex K \r
+ of the C standard. \r
+\r
+flockfile, funlockfile, getc_unlocked, putc_unlocked, fwrite_unlocked, ...\r
+ **Accepted.** Provide functionality not provided by the standard (and \r
+ useful in light of the C11 addition of threading). Can be trivially \r
+ implemented in terms of the <threads.h> mutex functions and the bodies of \r
+ the existing I/O functions, and impossible to implement externally\r