stick with one malloc implementation for all

[uclinux-h8/uclibc-ng.git] / docs / Glibc_vs_uClibc_Differences.txt

diff --git a/docs/Glibc_vs_uClibc_Differences.txt b/docs/Glibc_vs_uClibc_Differences.txt
index 4ed2463..887f219 100644 (file)
--- a/docs/Glibc_vs_uClibc_Differences.txt
+++ b/docs/Glibc_vs_uClibc_Differences.txt
@@ -18,14 +18,7 @@ functionality have been omitted.
 When a new version of uClibc is released, you may or may not need to recompile
 all your binaries.
 
-4) malloc(0) in glibc returns a valid pointer to something(!?!?) while in
-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.  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
+4) glibc's malloc() implementation has behavior that is tunable via the
 MALLOC_CHECK_ environment variable.  This is primarily used to provide extra
 malloc debugging features.  These extended malloc debugging features are not
 available within uClibc.  There are many good malloc debugging libraries
@@ -66,7 +59,7 @@ encrypt_r, since these are not required by SuSv3.
 
 12) uClibc directly uses 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 linux kernel's arch specific 'struct stat'.
 
 14) uClibc's librt library currently lacks all aio routines, all clock
     routines, and all shm routines (only the timer routines and the mq