Bug 693001

Description of problem:
Right now, there is a huge debate going on between the WG14 working group (C99/C1x), Austin Group (POSIX 2008), and glibc implementers on the correct semantics of realloc(ptr,0).
http://austingroupbugs.net/view.php?id=400
http://sourceware.org/bugzilla/show_bug.cgi?id=12547

If Red Hat intends to comply with C1x or POSIX certification, then glibc _must_ provide a mode where realloc(ptr,0) complies with the standard.  However, in the current state of the debate, it looks like the C committee is at loggerheads with the glibc implementers (C claims that realloc(ptr,0) returning NULL is an error indication, hence ptr is still valid (this happens to match BSD semantics); glibc claims that realloc(ptr,0) returning NULL is a successful call to free(ptr)); worse, the conflict is extremely dangerous to ALL programs:

If code is written assuming glibc semantics but run on a system with the argued C semantics, you have a memory leak (either ptr, or the new non-NULL return value that the code was not expecting, will be leaked).  If code is written assuming C1x semantics but run on a system with the argued glibc semantics, you have a double free (realloc freed ptr, but because it returned NULL and the program assumes ptr is still valid, the program frees ptr again).  Either way, an application loses if _ANY_ standards document requires exactly one behavior rather than documenting both historical behaviors and warning applications of the portability pitfalls if they are not aware of both behaviors.

Can Red Hat please step up its involvement with WG14 to request that the C1x ballot be changed to support glibc's current implementation (effectively by recommending that realloc(ptr,0) be given implementation-defined semantics and effectively be labeled non-portable in practice) rather than hard-lining their current interpretation that realloc(ptr,0) must not return NULL if it freed ptr?