From a4ba059034124cbdc0232b805a7fdf07994c8618 Mon Sep 17 00:00:00 2001 From: Eric Andersen Date: Fri, 8 Aug 2003 10:30:12 +0000 Subject: Add in a MALLOC_GLIBC_COMPAT option to let people decide if they want glibc style malloc(0) behavior --- extra/Configs/Config.in | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) (limited to 'extra') 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 -- cgit v1.2.3