Re: glibc realloc(ptr, 0) vs. C17 specification

[Florian Weimer <fw at deneb dot enyo dot de>]

* Eric Blake:

> tl;dr: the POSIX folks need glibc developer input on what appears to be
> a contradiction between the C17 standard and glibc realloc(ptr,0) behavior.
>
> Full details:
> The Austin Group (the organization in charge of the POSIX specification)
> is working towards the next version of POSIX; the current POSIX 2017
> (Issue 7) is based on C99, but the next version of POSIX (several years
> out still) will be based on C17.  But in preparing to update the C
> standard used by POSIX, we ran into a change in the C standard that
> appears on the surface to either be at odds with the glibc behavior, or
> to be internally self-inconsistent.

The C17 change is supposed not to change anything because the whole
edition is supposed to consist of editorial changes only.  (I've been
told.)  There is no intent to mandate changes to such a core function
as realloc.

> By a strict reading of 7.22.3.1 in isolation, this changes the
> requirements to state that realloc(a, b) cannot return NULL except to
> indicate an error (whereas C11 allowed a return of NULL even on
> success); but this is at odds with glibc behavior (where realloc(ptr,0)
> frees ptr but returns NULL as an indication of success).

I think the wording in C17 could even allow implementations where
realloc (ptr, 0) is a compaction hint, indicating that the allocator
can move the memory block without changing its size.  I think this
interpretation is not the intended one, though.  As far as I know, the
intent was to encompass the behavior of all current implementations,
without requiring changes from any implementation.

I don't expect we will make changes to glibc, no matter what C17 says.
Applications cannot rely on this behavior anyway because an interposed
malloc may have different behavior.