summaryrefslogtreecommitdiff
path: root/extra/Configs/Config.in
diff options
context:
space:
mode:
authorEric Andersen <andersen@codepoet.org>2003-08-08 10:30:12 +0000
committerEric Andersen <andersen@codepoet.org>2003-08-08 10:30:12 +0000
commita4ba059034124cbdc0232b805a7fdf07994c8618 (patch)
tree404770803bdcb542f8f5fc82baaf07509e5a06e9 /extra/Configs/Config.in
parentea9f6e1e2d60bac4e2c7f1fb9ee98f581a7c6229 (diff)
Add in a MALLOC_GLIBC_COMPAT option to let people decide if they
want glibc style malloc(0) behavior
Diffstat (limited to 'extra/Configs/Config.in')
-rw-r--r--extra/Configs/Config.in19
1 files changed, 18 insertions, 1 deletions
diff --git a/extra/Configs/Config.in b/extra/Configs/Config.in
index 92a3878ff..f77a4e4b5 100644
--- a/extra/Configs/Config.in
+++ b/extra/Configs/Config.in
@@ -195,11 +195,28 @@ config MALLOC_930716
endchoice
+config MALLOC_GLIBC_COMPAT
+ bool "Malloc returns live pointer for malloc(0)"
+ default n
+ help
+ The behavior of malloc(0) is listed as implementation-defined by
+ SuSv3. Glibc returns a valid pointer to something, while uClibc
+ normally return a NULL. I personally feel glibc's behavior is
+ not particularly safe, and allows buggy applications to hide very
+ serious problems.
+
+ When this option is enabled, uClibc will act just like glibc, and
+ return a live pointer when someone calls malloc(0). This pointer
+ provides a malloc'ed area with a size of 1 byte. This feature is
+ mostly useful when dealing with applications using autoconf's broken
+ AC_FUNC_MALLOC macro (which redefines malloc as rpl_malloc if it
+ does not detect glibc style returning-a-valid-pointer-for-malloc(0)
+ behavior). Most people can safely answer N.
+
config UCLIBC_DYNAMIC_ATEXIT
bool "Dynamic atexit() Support"
default y
help
-
When this option is enabled, uClibc will support an infinite number,
of atexit() and on_exit() functions, limited only by your available
memory. This can be important when uClibc is used with C++, since