[PATCH] malloc: add free_sized and free_aligned_sized from C23

[Justin King]

>
> Should we exclude memalign etc. as well?


The standard is quiet, as far as I know, on this since they do not exist in
the standard. So that will be up to glibc, but we should keep in mind
whatever glibc chooses very well may become the defacto standard on this.
The sanitizers, which are being updated (by me) to support free_sized and
free_aligned_sized, will enforce whatever we choose here.

Perhaps we say that if the malloc-like function accepts explicit alignment
(memalign/posix_memalign/aligned_alloc), it is undefined behavior to call
free_sized. And permit those functions to call free_aligned_sized. And just
say functions like valloc/pvalloc should not call free_sized, but may call
free_aligned_sized so long as they replicate the documented size and
alignment values. So for valloc free_aligned_sized must be called with
sysconf(_SC_PAGESIZE) for alignment and original requested size; pvalloc
free_aligned_sized must be called with sysconf(_SC_PAGESIZE) for alignment
and the original requested size rounded up to a multiple of
sysconf(_SC_PAGESIZE). We can mention that if you use valloc/pvalloc, we
strongly recommend continuing to use free instead due to the subtlety.

I'll update the lines and include some basic tests.


On Wed, Jun 18, 2025 at 8:56 AM Florian Weimer <fweimer@redhat.com> wrote:

> * Justin King:
>
> > +@deftypefun void free_aligned_sized (void *@var{ptr}, size_t
> @var{alignment}, size_t @var{size})
> > +@standards{???, stdlib.h}
> > +@safety{@prelim{}@mtsafe{}@asunsafe{@asulock{}}@acunsafe{@aculock{}
> @acsfd{} @acsmem{}}}
> > +The @code{free_aligned_sized} function deallocates the block of memory
> pointed at by @var{ptr} that
> > +was previously allocated by @code{aligned_alloc}. The size @var{size}
> and alignment @var{alignment}
> > +must match the previously requested total size and alignment provided
> to @code{aligned_alloc}. Attempting
> > +to deallocated memory allocated by @code{malloc}, @code{calloc} or
> @code{realloc} is undefined behavior.
>
> (These lines a re little bit long.)
>
> Should we exclude memalign etc. as well?
>
> Overall the patch looks okay to me.  The symbols are weak, so static
> linking against applications which define their own free_sized symbol
> still works.  Nothing calls these functions inside glibc, so there are
> no linknamespace problems.
>
> Thanks,
> Florian
>
>

-- 

[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/20250618/1306348a/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/20250618/1306348a/attachment.p7s>