[PATCH v9] malloc: add free_sized and free_aligned_sized from C23

[Justin King]

> Sorry if I came in late, but wouldn't callers be a bit faster if stdlib.h
also had something like this macro?

That would generally be a bad idea, as custom malloc implementations would
not be able to take advantage of providing their own
optimal implementation. Anybody using the standard library headers would
never actually use the symbols.

On Mon, Oct 20, 2025 at 9:42 AM Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 2025-10-20 08:42, Justin King wrote:
> > +extern void free_sized (void *__ptr, size_t __size) __THROW;
>
> Sorry if I came in late, but wouldn't callers be a bit faster if
> stdlib.h also had something like this macro?
>
> #define free_sized(ptr, size) ((void) (size_t) { (size) }, free (ptr))
>
> That would avoid some jump insns and/or dynamic linking hassles, because
> calling code would go straight to ordinary 'free' rather than a call to
> a jump.
>
> Similarly for free_aligned.
>
> If there's some reason we don't do that, a comment explaining why would
> be helpful.
>
>
> > +/* Free a block allocated by `malloc`, `realloc` or `calloc` but not
>
> Let's not use markup-style grave accents in include files; traditional
> ordinary apostrophes are fine.
>


-- 

[image: Google Logo]
Justin King
Software Engineer
jcking@google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251020/55152a26/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5277 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20251020/55152a26/attachment-0001.p7s>