Date: Thu, 29 Jun 2006 14:21:06 +0200 From: Andre Albsmeier <Andre.Albsmeier@siemens.com> To: Lowell Gilbert <lgusenet@be-well.ilk.org> Cc: freebsd-hackers@freebsd.org, Andre Albsmeier <Andre.Albsmeier@siemens.com> Subject: Re: Return value of malloc(0) Message-ID: <20060629122106.GA79420@curry.mchp.siemens.de> In-Reply-To: <44wtb12fu0.fsf@be-well.ilk.org> References: <20060628181045.GA54915@curry.mchp.siemens.de> <44wtb12fu0.fsf@be-well.ilk.org>
index | next in thread | previous in thread | raw e-mail
On Wed, 28-Jun-2006 at 16:19:35 -0400, Lowell Gilbert wrote:
> Andre Albsmeier <Andre.Albsmeier@siemens.com> writes:
>
> >
> > The manpage makes me think that when malloc is called with 0
> > as argument (and no V-flag had been set) the pointer it returns
> > can actually be used (as a pointer to the so-called "minimal
> > allocation"). It seems, that firefox "thinks" the same way :-).
> > However, it is calculated in malloc.c as a constant and is
> > always 0x800 (on my architecture). Any access to this area
> > results in a SIGSEV.
>
> The C standard explicitly allows both behaviours, and requires the
> implementation to choose one of them. If it returns a non-NULL
> pointer, though, that pointer can *only* be used for passing back to
> free(). It may *not* be dereferenced. So firefox is wrong, and
> actually broken.
Very good. I am glad this is clearly defined.
>
> > I assume the behaviour is meant to show up programming errors:
> >
> > "If you use malloc(0) and are crazy enough to access the 'allocated'
> > memory we give you a SIGSEV to show you how dumb you are :-)".
>
> Yes.
>
> > In this case the manpage is wrong (or, at least, mis-leading) and
> > should be fixed (I could give it a try if someone actually is willing
> > to commit it).
>
> I don't see what you are claiming is wrong. Can you give a brief
It says:
"The default behavior is to make a minimal allocation and return
a pointer to it."
This sounds as if it allocated some (!) bytes so the application
can use it. Yes, I know that 0 would be minimal as well :-). And
if you look into malloc.c you will see that, in fact, it doesn't
allocate anything at all:
} else if (!size) {
if (ptr != NULL)
ifree(ptr);
r = ZEROSIZEPTR;
r ist returned later and ZEROSIZEPTR is a constant.
> description of you're suggesting.
Hmm, let's see:
The default behavior is to return a non-NULL pointer which may
be passed to free() but does not point to any memory which can
be used by the application.
>
> > Apart from that, I suggest, we should run firefox (and maybe other
> > mozilla apps) with MALLOC_OPTIONS=V.
>
> That would be reasonable, particularly for the time being. However,
> the firefox bug really should be fixed in the upstream sources.
In this case, yes, of course.
-Andre
> Writing past the end of an allocated buffer (which is what the code
> does, if you think about it) is a serious error.
>
> > Another position could be that firefox is wrong because it NEVER
> > may use ANY return value of a malloc(0), regardless of its content.
>
> The C language standard agrees with this position...
--
Micro$oft: When will your system crash today?
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060629122106.GA79420>