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":
No, please no. These interfaces (generic void* allocators that take a
void** argument to store the result in) are an *extremely bad
antipattern* that produces undefined behavior. What you end up with
are things of the form:
T *p;
reallocp((void **)&p, size);
which is obviously UB to us, but not to your average C programmer.
They just think it's what you're supposed to do when the compiler
tells you there's a type mismatch.
The only well-defined way to use such an interface is hideously ugly,
and no one does it:
T *p;
void *tmp = p;
reallocp(&tmp, size);
if (success) p = tmp;
Please note that this issue is not theoretical. I've encountered it in
the wild with posix_memalign, cudamalloc(), libavcoded allocation
functions, etc. Often folks build machinery on top of these where it's
impossible to extricate the UB without major architectural changes to
the code. The "double-pointer allocate" idiom just needs to be burned
with fire.
Rich
