Paul Eggert wrote:
> For gnulib readers: this new bug-gnulib thread is following up on this
> long libc-alpha thread:
>
> https://sourceware.org/pipermail/libc-alpha/2024-October/160645.html
Thanks for the context, Paul.
I haven't read the entire thread. Is the following summary (from a
summarization engine) correct?
"In conclusion, although there is awareness that glibc's handling
of realloc(p, 0) may need to change to align with newer standards,
the consensus for now is to wait for further developments in both
POSIX and C standards before making any modifications."
If not, can you please summarize the conclusions?
The most recent standard, ISO C 23, says that if ptr != NULL and size == 0
"the behavior is undefined".
1) The Gnulib documentation (file doc/posix-functions/realloc.texi) says:
"Gnulib provides a module @samp{realloc-gnu} that substitutes a
realloc implementation that behaves more like the glibc implementation."
That is in line with what the *-gnu modules do.
So, it would be premature to change lib/realloc.c, _before_ glibc has
made any change.
2) More importantly, we need to consider the impact on programs.
According to our doc, there are three possible behaviours of the realloc
function:
With a non-NULL pointer argument p, C17 says that it is
implementation-defined whether realloc (p, 0) frees p. Behavior varies on
(A) whether realloc (p, 0) always frees p and successfully returns a
null pointer, or
(B) always fails and leaves p valid, or
(C) usually succeeds and returns a unique zero-size object.
And there is also
(D) usually succeeds and returns a pointer to freshly-allocated memory
of 1 byte.
(I believe we should mention this fourth possibility in
doc/posix-functions/realloc.texi.)
As I understand, the proposal is that glibc switches from (A) to (D).
For a program that expects behaviour (A), it may or may not result in a
memory leak. That depends on the program's logic. So, additional work for
the developer, to verify that they have no memory leak.
For a program that expects behaviour (D), but is run on an older platform
or with the existing gnulib module 'realloc-gnu', in may result in error
messages and cancelled computations. So, additional work for the developer
in this case as well.
That's not what Gnulib is made for: causing additional work for the
developer. Therefore, I don't think Gnulib should make such a change.
3) When behaviour changes are needed in Gnulib APIs, what we usually do is
a transition period, in which the developer is helped through appropriate
warnings or error messages.
What I would therefore suggest — if we want to change Gnulib at all
regarding realloc — is to make
realloc (ptr, 0) with ptr != NULL
abort.
This is allowed by ISO C 23.
We can do this for a transition period of 3 years. And then, in 3 years,
look what behaviour (A, B, C, or D) would be useful to have, considering
what glibc has done until then.
The developer would get a clear error message, with a gdb stack trace,
when this occurs.
Note that this is different from the way a zero size is handled in memcpy(),
memset(), et al.
(cf. <https://lists.gnu.org/archive/html/bug-gnulib/2024-10/msg00032.html>).
There, applications don't risk to run into memory leaks or errors when
memcpy() starts to support a zero size in the obvious way. The realloc()
situation is special because of (A), (B), (C), (D).
Bruno
