summaryrefslogtreecommitdiff
path: root/docs/Glibc_vs_uClibc_Differences.txt
diff options
context:
space:
mode:
Diffstat (limited to 'docs/Glibc_vs_uClibc_Differences.txt')
-rw-r--r--docs/Glibc_vs_uClibc_Differences.txt8
1 files changed, 8 insertions, 0 deletions
diff --git a/docs/Glibc_vs_uClibc_Differences.txt b/docs/Glibc_vs_uClibc_Differences.txt
index 89edd6e4f..7760d2321 100644
--- a/docs/Glibc_vs_uClibc_Differences.txt
+++ b/docs/Glibc_vs_uClibc_Differences.txt
@@ -24,6 +24,14 @@ 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.
+4.1) 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
+available for Linux (dmalloc, electric fence, valgrind, etc) that work much
+better than the glibc extended malloc debugging. So our omitting this
+functionality from uClibc is not a great loss.
+
5) uClibc does not provide a database library (libdb).
6) uClibc does not support NSS (/lib/libnss_*), which allows glibc to easily