[PATCH] malloc: add free_sized and free_aligned_sized from C23

[Justin King]

>
> I realized that we probably have another gap: Can a pointer returned
> from strdup and strndup be used with free_sized, and what should be size
> to pass?  Is this aspect covered in the C23 standard?  If the language
> is used is “as if by malloc”, this would be rather unfortunate because
> it implies that free_sized can be used, somehow.  If it's been changed
> to “suitable for passing to free and realloc”, we are good.


The last freely available revision for C23 says the following for
free_sized:

If ptr is a null pointer or the result obtained from a call to malloc,
> realloc, or calloc, where size
> size is equal to the requested allocation size, this function is
> equivalent to free(ptr). Otherwise,
> the behavior is undefined.


So since the size of underlying allocation implemented by strdup and
strndup is not known to the caller (a valid implementation could request
more than necessary), that would make calling free_sized undefined
behavior. Additionally the documentation for `strdup` says to call free and
does not mention free_sized. So it should be okay to forbid it.

I think we should go with some sort of explanation that basically says: do
not use free_sized or free_aligned_sized unless you also directly made the
call to allocate, use free instead. Needs some wordsmithing.

And I just realized that we should also say that it is NOT possible to
> recover the alignment and size from the pointer and via
> malloc_usable_size.


Unfortunately the standard mentions the following in recommended practice:

Implementations may provide extensions to query the usable size of an
> allocation, or to determine
> the usable size of the allocation that would result if a request for some
> other size were to succeed.
> Such implementations should allow passing the resulting usable size as the
> size parameter, and
> provide functionality equivalent to free in such cases.


Since it's in recommended practice, we can however choose to treat it as a
sign and not a cop and forbid it. I am fine with that. It is easier to
relax behaviors later than it is to claw back.

+Chris Kennelly <ckennelly@google.com> who was one of the authors for
free_sized and free_aligned_sized

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

> * 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.
>
> Right.
>
> > 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.
>
> Note that with valloc, callers would have to round up the allocation
> size if used with free_aligned_sized.  I suggest not to go there at all.
> We should perhaps allow posix_memalign in addition to aligned_alloc, but
> that's it.
>
> I realized that we probably have another gap: Can a pointer returned
> from strdup and strndup be used with free_sized, and what should be size
> to pass?  Is this aspect covered in the C23 standard?  If the language
> is used is “as if by malloc”, this would be rather unfortunate because
> it implies that free_sized can be used, somehow.  If it's been changed
> to “suitable for passing to free and realloc”, we are good.
>
> From what I can see, we should not allow the use of any of these
> secondary allocation functions.  (We also have asprintf, open_memstream,
> realpath, and a couple more.)  The manual should be explicit about this.
> And I just realized that we should also say that it is NOT possible to
> recover the alignment and size from the pointer and via
> malloc_usable_size.
>
> 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/79cff818/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/79cff818/attachment.p7s>