	  -------------------------------------------------
	  Please note the following caveats to using klibc:
	  -------------------------------------------------

optimization:
-------------

Compiling with -O0 is not supported.  It may or may not work; please
use -O1 if you want to do maximize debuggability.

Compiling with -O0 is more likely to work on gcc 3.


setjmp()/longjmp():
-------------------

setjmp() and longjmp() *do not* save signal state.  sigsetjmp() and
siglongjmp() *do* save the signal mask -- regardless of the value of
the extra argument.

The standards actually state that if you pass longjmp() a final value
of zero the library should change that to a 1!  Presumably the reason
is so people who write broken code can get away with writing
longjmp(buf); or something equally bad.  If you pass longjmp() a final
value of 0 you get what you deserve -- setjmp() will happily return 0.


stdio:
------

Only a small subset of the stdio functions are implemented.  Those
that are implemented do not buffer, although they *do* trap EINTR or
short read/writes and iterate.

_fread() and _fwrite(), which take only one size argument (like
read/write), but do handle EINTR/short return are also available.


namespaces:
-----------

klibc frequently includes headers in other headers in a way that
exposes more symbols than POSIX says they should.  "Live with it."


theading:
---------

klibc is not thread-safe.  Consequently, clone() or any of the
pthreads functions are not included.


bsd_signal vs sysv_signal:
--------------------------

There is no signal() call, because you never know if you want
Linux/SysV semantics (SA_RESETHAND) or GNU/BSD semantics (SA_RESTART).
The best, in *any* circumstances, is to never use signal() and instead
use sigaction(), but in order to simplify porting you can use either
sysv_signal() or bsd_signal(), depending on what you actually want.