summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
Diffstat (limited to 'docs')
-rw-r--r--docs/Glibc_vs_uClibc_Differences.txt12
-rw-r--r--docs/uClibc_vs_SuSv3.txt8
-rw-r--r--docs/uclibc.org/FAQ.html34
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>