On Thu, 21 Jan 2010, Markus Armbruster wrote: > malc <av1...@comtv.ru> writes: > > > On Thu, 21 Jan 2010, Markus Armbruster wrote:
[..snip..] > >> No, this is a misinterpretation of the C99 standard, made possible by > >> its poor wording. The C99 Rationale is perfectly clear, though: > > > > You have to show the flaw in Hallvard B Furuseth's analysis to claim > > that it's a misinterpretation. And unlike the standard rationale is > > non normative. > > > > [..snip..] > > I did. If that doesn't convince you, I'll gladly wait for the Technical > Corrigendum that'll put this rather absurd misreading to rest. If you did, then, i guess, i've missed it, here's the whole analysis, please point what and where is wrong: [quote: http://groups.google.com/group/comp.std.c/browse_thread/thread/4e9af8847613d71f/6f75ad22e0768a0b?q=realloc++group:comp.std.c#6f75ad22e0768a0b] C90 said realloc(non-null, 0) did free(). C99 inverted that, saying it does not: The only place where 7.20.3.4 (The realloc function) mentions that realloc may free the old object, is in the case where it returns another object. 7.20.3 (Memory management functions) says zero-sized allocation returns NULL, but 7.20.3.4 overrides that. Could we have the original behavior back, please? I've seen people say the current definition is unintentional. And it conflicts with the C99 Rationale: 7.20.3.4 The realloc function (...) 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, though that goes on with and a null argument may be returned; C99 is consistent with the policy of not allowing zero-sized objects. Is that supposed to mean no new object is returned but the return value is indeterminate, or does it mean that it might free the old object and return an inaccessible new object like malloc(0)? Repeating from old realloc(non-null, 0) discussions: In the latter case a program which sees a NULL return from realloc(non-null, 0) cannot know if the old object was freed or not - i.e. it cannot know if the NULL was a failure return (from allocating the new object) or a success return (after freeing the old object). Which is exactly the situation for a portable program which sees such a NULL return today - it cannot know if it was a C99 failure return or a C90 success return. Even if the language is C99, the library might be C90. [end quote] -- mailto:av1...@comtv.ru
