malc <av1...@comtv.ru> 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; [...]
This is hardly surprising, because anything else would break working C89
programs, and that would squarely contradict the standard's mission, as
explained in the Rationale:
Avoid "quiet changes." Any change to widespread practice altering
the meaning of existing code causes problems. Changes that cause
code to be so ill-formed as to require diagnostic messages are at
least easy to detect. As much as seemed possible consistent with its
other goals, the C89 Committee avoided changes that quietly alter
one valid program to another with different semantics, that cause a
working program to work differently without notice. In important
places where this principle is violated, both the C89 Rationale and
this Rationale point out a QUIET CHANGE.
The only quiet change in the Rationale regarding malloc() & friends is
this one:
QUIET CHANGE IN C89
A program which relies on size-zero allocation requests returning a
non-null pointer will behave differently.
For what it's worth, I checked my facts with a member of the C
committee.
>> See also http://c-faq.com/malloc/reallocnull.html which says "and the
>> related realloc(..., 0), which frees" and has references at the end.
>> See, it's not just me :-)
>
> Nope not just you, even glibc still uses C90 behaviour.
Because it reads the standard correctly, just like the comp.lang.c FAQ
Aurelien quoted.
[...]
