[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250620143631.GK2742@qaa.vinc17.org>
Date: Fri, 20 Jun 2025 16:36:31 +0200
From: Vincent Lefevre <vincent@...c17.net>
To: Alejandro Colomar <alx@...nel.org>
Cc: Eric Blake <eblake@...hat.com>, Rich Felker <dalias@...c.org>,
enh <enh@...gle.com>, Florian Weimer <fweimer@...hat.com>,
Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>,
musl@...ts.openwall.com, libc-alpha@...rceware.org,
Joseph Myers <josmyers@...hat.com>,
наб <nabijaczleweli@...ijaczleweli.xyz>,
Paul Eggert <eggert@...ucla.edu>,
Robert Seacord <rcseacord@...il.com>,
Bruno Haible <bruno@...sp.org>, bug-gnulib@....org,
JeanHeyd Meneide <phdofthehouse@...il.com>,
Thorsten Glaser <tg@...bsd.de>
Subject: Re: Re: BUG: realloc(p,0) should be consistent with malloc(0)
On 2025-06-20 13:58:23 +0200, Alejandro Colomar wrote:
> On Fri, Jun 20, 2025 at 04:11:23AM +0200, Vincent Lefevre wrote:
> > You should also consider the end of 7.20.3p1 (which applies to calloc,
> > malloc and realloc):
> >
> > If the size of the space requested is zero, the behavior is
> > implementation-defined: either a null pointer is returned, or the
> > behavior is as if the size were some nonzero value, except that
> > the returned pointer shall not be used to access an object.
>
> Right. I missed that part.
>
> So, C99 and C11 allow realloc(p,0) to return a null pointer.
>
> > Consider the case "a null pointer is returned" with realloc(non_null,0).
> > I can see 2 possible interpretations:
> >
> > 1. This is always a failure (corresponding to "a null pointer if the
> > new object could not be allocated" in 7.20.3.4p4). But I doubt that
> > this is the intended behavior, as there would be major memory leaks
> > in practice with such an implementation and would make such a call
> > useless.
> >
> > 2. This means that the memory is entirely freed, which is a success.
> > This makes your assumption "paragraph 4 rules out the possibility of
> > returning a null pointer on success" above wrong. However, in order
> > to know whether a null pointer means a success (memory entirely freed)
> > or a failure (for the case "the behavior is as if the size were some
> > nonzero value"), the application would need to know which kind of
> > implementation it is (e.g. guessed by tools like configure tests).
>
> To disambiguate, we need to read
>
> <https://port70.net/~nsz/c/c99/n1256.html#7.20.3.4>
>
> First p4:
>
> 4 The realloc function returns a pointer to the new object
> (which may have the same value as a pointer to the old object),
> or a null pointer if the new object could not be allocated.
>
> So, a null pointer, which is allowed for r(p,0), means that "the new
> object could not be allocated".
>
> And then we read the last sentence of p3:
>
> 3 [...]
> If memory for the new object cannot be allocated,
> the old object is not deallocated and its value is unchanged.
>
> So, the input pointer must not be freed.
Yes, this is what I mentioned in interpretation 1 above (so with
memory leaks in practice, as applications call realloc(non_null,0)
to free memory, while memory will never be freed).
But I believe that this was not the intent of the C Committee.
If it were, the text would have been different, IMHO.
This is too late for a defect report anyway, as the current standard
is C23 and realloc(non_null,0) is now UB. But if one wants to avoid
the UB in a future standard, the above remarks need to be considered.
> I'd say glibc is non-conforming, even if this could possibly have been
> unintended by the C Committee.
Well, strictly speaking, with the UB, it is conforming (at least with
a non-null pointer). I'm not sure that speaking of conformity against
old standards makes sense if there is a suspicion of defect (and in
particular, if this has been resolved by a change in the current
standard, like here).
--
Vincent Lefèvre <vincent@...c17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
