1 -------------------------------------------------
2 Please note the following caveats to using klibc:
3 -------------------------------------------------
8 Compiling with -O0 is not supported. It may or may not work; please
9 use -O1 if you want to do maximize debuggability.
11 Compiling with -O0 is more likely to work on gcc 3.
17 setjmp() and longjmp() *do not* save signal state. sigsetjmp() and
18 siglongjmp() *do* save the signal mask -- regardless of the value of
21 The standards actually state that if you pass longjmp() a final value
22 of zero the library should change that to a 1! Presumably the reason
23 is so people who write broken code can get away with writing
24 longjmp(buf); or something equally bad. If you pass longjmp() a final
25 value of 0 you get what you deserve -- setjmp() will happily return 0.
31 Only a small subset of the stdio functions are implemented. Those
32 that are implemented do not buffer, although they *do* trap EINTR or
33 short read/writes and iterate.
35 _fread() and _fwrite(), which take only one size argument (like
36 read/write), but do handle EINTR/short return are also available.
42 klibc frequently includes headers in other headers in a way that
43 exposes more symbols than POSIX says they should. "Live with it."
49 klibc is not thread-safe. Consequently, clone() or any of the
50 pthreads functions are not included.
53 bsd_signal vs sysv_signal:
54 --------------------------
56 There is no signal() call, because you never know if you want
57 Linux/SysV semantics (SA_RESETHAND) or GNU/BSD semantics (SA_RESTART).
58 The best, in *any* circumstances, is to never use signal() and instead
59 use sigaction(), but in order to simplify porting you can use either
60 sysv_signal() or bsd_signal(), depending on what you actually want.