The definition of malloc_usable_size()

[Sam James]

"H. Peter Anvin" <hpa@zytor.com> writes:

> So the definition of malloc_usable_size() states:
>
> CAVEATS
>        The value returned by malloc_usable_size() may be greater than the re‐
>        quested size of the allocation because of various internal implementa‐
>        tion details, none of which the programmer should rely on.  This func‐
>        tion is intended to only be used for diagnostics and statistics; writ‐
>        ing  to  the  excess memory without first calling realloc(3) to resize
>        the allocation is not supported.  The returned value is only valid  at
>        the time of the call.
>
>
> Has *any* version of glibc actually behaved this way (meaning returned a value
> larger than what would actually be safe to use?)

DJ's reply covers this.

>
> The very name malloc_usable_size() strongly implies that this amount of memory
> is, well, usable, and as such this function name *strongly* violate the
> principle of least surprise.  As this is highly useful information for at
> least some types of applications, I would be *highly* surprised if there
> aren't applications out there which take advantage of it, regardless of this
> statement, unless there are versions of glibc for which this is explicitly not
> the case.
>
> If there *are*, I would strongly suggest deprecating this function with an
> explicit warning, and rename it something like __malloc_current_size() with
> the __ prefix to indicate that it is an implementation-specific function, and
> removing the word "usable" in the name.
>

We tried: https://inbox.sourceware.org/libc-alpha/20221124213258.305192-1-siddhesh@gotplt.org/

And I still think we should.

> 	-hpa

sam
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 418 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260504/f67f1d04/attachment.sig>