Hi H. Peter, On Sun, Jun 29, 2025 at 09:25:13AM -0700, H. Peter Anvin wrote: > On 2025-06-27 07:01, Alejandro Colomar wrote: > > Hi! > > > > Here's a new revision of the proposal, addressing some points raised by > > Mark, plus clarifying that the paragraph about when size is zero refers > > to the total size, as Florian was concerned that it might not be > > symmetric. > > I don't know if it would be useful, but proposing a new interface of the > form: > > reallocp(&ptr, size) > > ... to separate the status return from the pointer might be a really good > idea. This would hopefully eliminate users doing the "obvious": > > ptr = realloc(ptr, size)
This is resolved with the reallocf(3) wrapper that FreeBSD provides,
which I pretend to standardize *after* fixing realloc(3). This is
provided in Linux (and other POSIX) systems by the libbsd library,
present in many distros.
reallocf(3) is a realloc(3) wrapper that unconditionally frees the
input pointer, even on error. So, it is designed to be used exactly as
p = reallocf(p, size);
if (p == NULL)
goto err;
As simple as it gets.
> Not that this resolves anything in the short or even medium term, but
> perhaps can help avoid problems in the more distant time frame. It is also
> an interface which is mostly trivial to infill.
No, this would make static analysis a lot harder. Currently, realloc(3)
is specified as ending the lifetime of the input object, and creating a
new one, and a static analyzer could easily understand that with
attributes like the existing [[gnu::malloc(free)]] --although for some
reason, there's no similar existing attribute for realloc(3)--.
However, if the new object is created in the parameter, you'll have a
very hard time tracking that.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
