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

[Justin King]

> First, OK that's fine, but how about putting that in a comment? It could
> be either in the .h file or in the .c source files.

Sorry, I may have come off harsh. Commenting about why something is
not a macro is kind of the opposite justification, no? Not using a macro
would be the obvious choice IMO. Does glibc use macros in that fashion
for other functions defined by the C standard? Typically one should use
inline functions. I can add a comment, but it feels like explaining the
obvious
and I am not sure it's totally useful.

> Second, doesn't this mean the "Replacing malloc" section should talk
> about the need to replace free_sized and free_aligned_sized, in the
> section where it currently talks about replacing aligned_alloc etc.?

We can, but it's not absolutely necessary today. You do not have to
override them, as currently they both default to calling free. So during
replacing, they should both forward to the overridden free. But it is
probably
a good idea to mention that going forward, it is a good idea to replace them
as well. I'll do that.

On Mon, Oct 20, 2025 at 4:08 PM Paul Eggert <eggert@cs.ucla.edu> wrote:

> On 2025-10-20 10:00, Justin King wrote:
> > That would generally be a bad idea, as custom malloc implementations
> would
> > not be able to take advantage of providing their own
> > optimal implementation.
>
> First, OK that's fine, but how about putting that in a comment? It could
> be either in the .h file or in the .c source files.
>
> Second, doesn't this mean the "Replacing malloc" section should talk
> about the need to replace free_sized and free_aligned_sized, in the
> section where it currently talks about replacing aligned_alloc etc.?
>


-- 

[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/09d1b050/attachment.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/09d1b050/attachment.p7s>