Date: Thu, 02 Dec 2004 11:44:20 +0100 From: Andre Oppermann <andre@freebsd.org> To: "" Cc: current@FreeBSD.org Subject: Re: malloc(0) returns an invalid address Message-ID: <41AEF204.2070402@freebsd.org> In-Reply-To: <y7v1xe9p87u.wl@ocean.jinmei.org> References: <y7vfz2qpltw.wl@ocean.jinmei.org> <MDEHLPKNGKAHNMBLJOLKMEAKADAB.davids@webmaster.com> <y7v1xe9p87u.wl@ocean.jinmei.org>
next in thread | previous in thread | raw e-mail | index | archive | help
JINMEI Tatuya / 神明達哉 wrote: >>>>>>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. man malloc(3) and look for options 'V' and 'X'. >>>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". -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41AEF204.2070402>