Date: Thu, 02 Dec 2004 14:41:57 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: davids@webmaster.com Cc: current@FreeBSD.org Subject: Re: malloc(0) returns an invalid address Message-ID: <y7v1xe9p87u.wl@ocean.jinmei.org> In-Reply-To: <MDEHLPKNGKAHNMBLJOLKMEAKADAB.davids@webmaster.com> References: <y7vfz2qpltw.wl@ocean.jinmei.org> <MDEHLPKNGKAHNMBLJOLKMEAKADAB.davids@webmaster.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Wed, 1 Dec 2004 07:49:54 -0800, >>>>> "David Schwartz" <davids@webmaster.com> said: >> % ./a.out >> address of p is 0x800 >> zsh: 645 segmentation fault (core dumped) ./a.out > This should fault. Although the return value of 'malloc(0)' is a valid > pointer, once you cast it to a 'char *', you cannot dereference it because > it does not point to a character. This same problem would occur with > 'malloc(1)' and 'int *'. I expected the answer:-) This is probably a matter of the definition of "validness", and I won't argue about this point. (and, of course, it cannot be justified to dereference a zero-length pointer, whether the result is segfault or not) BTW: the "same problem" (of segfault) does actually NOT occur with malloc(1) and int * on FreeBSD 5.3 (i386). I suspect malloc(3) takes a special action with the size of zero. >> So, if we wanted to call 0x800 "a valid pointer just with >> not-enough-size", it would be fine. But then we need to implement the >> same logic in the kernel to provide consistent behavior. (I would >> "fix" the malloc behavior though). > The malloc behavior is not broken, so it cannot be fixed. The kernel check > semantics in 'useracc' are wrong for zero lengths. Okay, I'll be happy as long as the library and the kernel provide the consistent behavior on which pointer is "valid". Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. is it better for me to file a separate bug report on this?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7v1xe9p87u.wl>