malc <av1...@comtv.ru> writes: > On Thu, 21 Jan 2010, Jamie Lokier wrote: > >> Markus Armbruster wrote: >> > 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; [...] >> >> 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?
