diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/Glibc_vs_uClibc_Differences.txt | 12 | ||||
| -rw-r--r-- | docs/uClibc_vs_SuSv3.txt | 8 | ||||
| -rw-r--r-- | docs/uclibc.org/FAQ.html | 34 |
3 files changed, 29 insertions, 25 deletions
diff --git a/docs/Glibc_vs_uClibc_Differences.txt b/docs/Glibc_vs_uClibc_Differences.txt index 7760d2321..e557b56be 100644 --- a/docs/Glibc_vs_uClibc_Differences.txt +++ b/docs/Glibc_vs_uClibc_Differences.txt @@ -22,7 +22,8 @@ all your binaries. uClibc calling malloc(0) returns a NULL. The behavior of malloc(0) is listed as implementation-defined by SuSv3, so both libraries are equally correct. This difference also applies to realloc(NULL, 0). I personally feel glibc's -behavior is not particularly safe. +behavior is not particularly safe. To enable glibc behavior, one has to +explicitly enable the MALLOC_GLIBC_COMPAT option. 4.1) glibc's malloc() implementation has behavior that is tunable via the MALLOC_CHECK_ environment variable. This is primarily used to provide extra @@ -62,14 +63,11 @@ then the long double support is quite limited. 11) uClibc's libcrypt does not support the reentrant crypt_r, setkey_r and encrypt_r, since these are not required by SuSv3. -12) uClibc does not implement wordexp() +12) uClibc directly uses the kernel types to define most opaque data types. +13) uClibc directly uses the linux kernel's arch specific 'stuct stat'. -13) uClibc directly uses the kernel types to define most opaque data types. - -14) uClibc directly uses the linux kernel's arch specific 'stuct stat'. - -15) Add other things here as they come up...... +14) Add other things here as they come up...... diff --git a/docs/uClibc_vs_SuSv3.txt b/docs/uClibc_vs_SuSv3.txt index a86328a58..bae433050 100644 --- a/docs/uClibc_vs_SuSv3.txt +++ b/docs/uClibc_vs_SuSv3.txt @@ -25,10 +25,10 @@ and the requirements of the SuSv3. call has finished. 2) Some functions required by SuSv3 are not currently implemented. - The function you are mostly likely to encounter is wordexp(). - A couple of years ago, nobody used wordexp. Now some apps do. - One of these days, someone may provide us with a well written - patch to implement it... + Functions listed by SuSv3 but not (yet) included in uClibc: + + fmtmsg, ftw, nftw, <dunno for certain> + More to follow when we think of it... diff --git a/docs/uclibc.org/FAQ.html b/docs/uclibc.org/FAQ.html index 23af6d53a..e9e3019cc 100644 --- a/docs/uclibc.org/FAQ.html +++ b/docs/uclibc.org/FAQ.html @@ -109,20 +109,26 @@ to the uClibc home page.</a> </TD></TR> <TR><TD BGCOLOR="#eeeee0"> - uClibc has been designed from the ground up to be a C library for - embedded Linux. We don't need to worry about things like MS-DOS - support, or BeOS, or AmigaOs any other system. This lets us cut out - a lot of complexity and very carefully optimize for Linux. By very - careful design, we can also take a few shortcuts. For example, glibc - contains an implementation of the wordexp() function, in compliance - with the Single Unix Specification, version 3. Well, standards are - important. But so is pragmatism. The wordexp function is huge, yet I - am not aware of even one Linux application that uses it! So uClibc - doesn't provide wordexp(). There are many similar examples. In other - cases, uClibc leaves certain features (such as full C99 Math library - support, IPV6, and RPC support) disabled by default. Those features - can be enabled for people that need them, but are otherwise disabled to - save space. + uClibc has been designed from the ground up to be a C library for embedded + Linux. We don't need to worry about things like MS-DOS support, or BeOS, + or AmigaOs any other system. This lets us cut out a lot of complexity and + very carefully optimize for Linux. By very careful design, we can also + take a few shortcuts. +<!-- FIXME + For example, glibc's stdio code (handling things + like printf, scanf, fopen, etc) has been evolved over many years by + patching various bits of additional functionality as needed. uClibc's + stdio code was written by just one person, and was carefully designed from + the outset to comply with the latest standards while carefully reusing code + and being as small and configurable as possible, In this way, uClibc's + stdio code... + + There are many similar examples. +--> + In other cases, uClibc + leaves certain features (such as full C99 Math library support, IPV6, and + RPC support) disabled by default. Those features can be enabled for people + that need them, but are otherwise disabled to save space. <p> |