Re: [PATCH 12/14] doc: mention Solaris malloc ENOMEM issues

[Paul Eggert]

On 2024-11-05 07:40, Bruno Haible wrote:
> Huh? Solaris is not known for blatant POSIX violations, and the unit test
> that I added in tests/test-malloc-posix.c on 2024-10-31 passed on Solaris 11.4
> (with gcc).

I changed the doc because the Solaris 11.4 man page says that a failing 
malloc can set errno to EAGAIN instead of ENOMEM. And looking at the 
source code it appears that Solaris 11.4 malloc uses sbrk, whose man 
page also says it can set errno to EAGAIN on failure.

Also, setting errno=EAGAIN is not a POSIX violation. See the malloc 
rationale 
<https://pubs.opengroup.org/onlinepubs/9799919799/functions/malloc.html#tag_17_322_08>. 
A failing malloc can set errno to EAGAIN or to any other positive value, 
such as EMFILE.

There is an ambiguity in POSIX here, for realloc. If P is nonnull and 
realloc (P, 0) sets errno to EINVAL and returns NULL, the caller does 
not know whether the realloc succeeded or failed and therefore does not 
know whether P remains valid. In practice such behavior always means 
success and P has become invalid, and code that is written that way will 
still operate correctly (albeit with memory leaks) on the 
only-theoretical platforms that theoretically behave the other way.

This underscores the point that, although malloc-posix, realloc-posix, 
etc. check for POSIX conformance, they go somewhat beyond that and 
insist on behavior that POSIX does not require. And if this is true why 
do we distinguish between (say) malloc-posix and malloc-gnu?

I suppose this stuff should be documented better in Gnulib.