From 013f366f501c928315cc2893f0f2348c8956d09e Mon Sep 17 00:00:00 2001 From: Waldemar Brodkorb Date: Tue, 20 Dec 2016 20:51:59 +0100 Subject: remove __MALLOC_GLIBC_COMPAT__ option This option is enabled for a long time and I see no useful case where we should be incompatible to glibc here. --- extra/Configs/Config.in | 17 ----------------- 1 file changed, 17 deletions(-) (limited to 'extra') diff --git a/extra/Configs/Config.in b/extra/Configs/Config.in index ed16611dd..05610aee2 100644 --- a/extra/Configs/Config.in +++ b/extra/Configs/Config.in @@ -610,23 +610,6 @@ config MALLOC_STANDARD endchoice -config MALLOC_GLIBC_COMPAT - bool "Malloc returns live pointer for malloc(0)" - help - The behavior of malloc(0) is listed as implementation-defined by - SuSv3. Glibc returns a valid pointer to something, while uClibc - normally returns 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_HAS_OBSTACK bool "Obstack Support (gnu extension)" help -- cgit v1.2.3