[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols a
From: |
malc |
Subject: |
Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present |
Date: |
Fri, 22 Jan 2010 21:54:20 +0300 (MSK) |
On Fri, 22 Jan 2010, Markus Armbruster wrote:
> malc <address@hidden> writes:
>
> > On Thu, 21 Jan 2010, Jamie Lokier wrote:
> >
> >> Markus Armbruster wrote:
> >> > malc <address@hidden> writes:
> >> >
> >> > > On Tue, 29 Dec 2009, Jamie Lokier wrote:
> >> > >
> >> > >> malc wrote:
> >> > >> > On Mon, 28 Dec 2009, Jamie Lokier wrote:
> >> > >> >
> >> > >> > > Aurelien Jarno wrote:
> >> > >> > > > This fixes the loading of a stripped kernel with zero malloc
> >> > >> > > > disabled.
> >> > >> > >
> >> > >> > > *Raises an eyebrow*
> >> > >> > >
> >> > >> > > Even though there's different perspectives over whether
> >> > >> > > qemu_malloc(0)
> >> > >> > > should be allowed, inherited from ambiguity over malloc(0),
> >> > >> > > realloc(p,0) has always had a standard, well-defined meaning.
> >> > >> >
> >> > >> > No.
> >> > >> > http://groups.google.com/group/comp.std.c/browse_thread/thread/4e9af8847613d71f/6f75ad22e0768a0b?q=realloc++group:comp.std.c#6f75ad22e0768a0b
> >> > >>
> >> > >> Wow, thanks for that. It's a real surprise. Looks like C99's own
> >> > >> rationale is not consistent with itself on the subject, and differs
> >> > >> from C90 where the "standard, well-defined meaning" I referred to was
> >> > >> defined.
> >> > >
> >> > > Yep.
> >> >
> >> > No, this is a misinterpretation of the C99 standard, made possible by
> >> > its poor wording. The C99 Rationale is perfectly clear, though:
> >> >
> >> > 7.20.3.4 The realloc function
> >> >
> >> > A null first argument is permissible. If the first argument is not
> >> > null, and the second argument is 0, then the call frees the memory
> >> > pointed to by the first argument, and a null argument may be
> >> > returned; [...]
> >>
> >> The rationale above does not match C89 behaviour. It says the call
> >> frees the memory, but it does not forbid the call from then proceeding
> >> to do the same as malloc(0) and return a non-NULL pointer. It's quite
> >> explicit: a null argument *may* be returned. Which means the
> >> rationale does not require realloc(p,0) to do the same as C89, which
> >> always frees the memory and doesn't allocate anything.
> >>
> >> > This is hardly surprising, because anything else would break working C89
> >> > programs, and that would squarely contradict the standard's mission,
> >>
> >> Understood. But it doesn't really matter what's intended or what's
> >> misinterpreted. If there are any significant implementations out
> >> there based on the "misinterpretation", or even based on the
> >> rationale, that's enough of a reason to not depend on realloc(p,0).
> >>
> >
> > My sentiment exactly.
> >
> > An example:
> >
> > Dinkum Unabridged Library was certified by Perennial
> > (http://peren.com/pages/aboutus_set.htm) to conform
> > to ISO/IEC 9899:1999.
> >
> > Documentation for realloc:
> > http://www.dinkumware.com/manuals/?manual=compleat&Search=realloc&page=stdlib.html#realloc
> >
> > Hallvard B Furuseth analysis fully applies i believe...
>
> Regardless of whether his analysis applies to this implementation's
> documentation or not: what does this implementation actually do?
>
I'd guess it follows it's own documentation, but i don't have it to
check, anyone?
--
mailto:address@hidden
Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present, Jamie Lokier, 2010/01/21
Re: [Qemu-devel] [PATCH] loader: don't call realloc(O) when no symbols are present, Markus Armbruster, 2010/01/21