Remove comments about wordexp.

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......
 
 
 

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...
 

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>