BUG: realloc(p,0) is not conforming to C99/C11/C17/POSIX.1-2008

[Maciej W. Rozycki]

On Mon, 28 Oct 2024, Paul Eggert wrote:

> >   A new paragraph begins saying what happens in one specific case:
> 
> The RETURN VALUE section gives two possibilities at the top level. The first
> is "Upon successful completion, ..."; the second is "If there is not enough
> available memory, ...". The specific case you mention, which lists as an
> option "A null pointer shall be returned", appears under the "Upon successful
> completion" possibility. This case is successful completion because the
> initial "Upon successful completion" sentence explicitly lists returning a
> null pointer as being successful.

 Maybe it's a matter of rendering the web page, or how the PDF version has 
been formatted that I have no access to.  I can see three possibilities at 
the top level; cf. the screenshot attached.

> Under the reading you gave, the RETURN VALUE section would jump back and forth
> and back and forth between describing successful and unsuccessful completion,
> with no hint to the reader as to which behavior is intended to be successful
> and which is not, and with one of the isolated unsuccessful-completion
> behaviors just happening to not apply to glibc. I don't find such a reading
> plausible: other RETURN VALUE sections consistently list successful completion
> behaviors first, then unsuccessful ones, and I see no reason why this RETURN
> VALUE section would differ from the general pattern.

 I see your point and maybe the EINVAL case would have been better listed 
in its own paragraph, although it being a case under one of two alternate 
options would have the potential to obfuscate the language even further.  
Please note too that EINVAL is also listed as an error explicitly under 
the "Errors" section.

 NB please observe how the structure of the "Return Value" section has 
changed from POSIX.1-2017 (which didn't mention EINVAL though, deferring 
to "an implementation-defined value" instead, not quoted in the "Errors" 
section either), perhaps to address this very issue.

 Otherwise it seems we have to agree to disagree.  I maintain that to set 
errno to a documented value constitutes an unsuccesful return; it would be 
inconsistent with all the other APIs otherwise.

> >  Also who does this certification?  The Austin Group or someone else?
> 
> It's the Open Group; see <https://posix.opengroup.org/>.

 Ack.  But as you say AIX was certified back in 2020, so it couldn't have 
complied to POSIX.1-2024, which was only finalised a couple months ago.  
With POSIX.1-2017 I would reluctantly agree that considering setting errno 
to said implementation-defined value a successful return case was arguably 
valid (though I'd request for a technical corrigendum to be issued instead 
if I came across it; maybe this is what actually happened).

  Maciej
-------------- next part --------------
A non-text attachment was scrubbed...
Name: realloc-return.png
Type: image/png
Size: 39163 bytes
Desc: 
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20241028/b873268c/attachment-0001.png>