[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHktk4gBN7kuSm2TkuhwMbNii5WPZ0ejnnauTwc6LSOk9H1odg@mail.gmail.com>
Date: Mon, 20 Apr 2026 19:21:13 -0700
From: Charles Munger <clm@...gle.com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Request for feedback on WG14 proposal N3849 (alloc_at_least)
On Mon, Apr 20, 2026, 4:56 PM Rich Felker <dalias@...c.org> wrote:
> On Mon, Apr 20, 2026 at 03:11:38PM -0700, Charles Munger wrote:
> > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3849.pdf
> >
> > On the WG14 mailing list it was raised that musl had objections to this
> > proposal and others dealing with exposing allocator sizes. I hope that I
> > and my coauthors wrote this in a way that would be unobjectionable to
> > allocator/libc maintainers, but if this will cause you problems I would
> > like to know, and welcome any and all of your feedback.
>
> I'm not sure what specific objections you're referring to. I have not
> seen concrete evidence that any of this has any practical value. I
> raised that objection early in the discussion of this whole topic, and
> I don't think anyone ever presented measurements that support the need
> for any action whatsoever here. In the absence of that, I do not think
> anything like this should be adopted.
>
I was motivated to propose this after an investigation where I found that
pathological allocation sizes were causing big performance problems in some
software I was working on (upb). I looked into using malloc_usable_size,
but that presented further problems with lookup performance costs, the need
to realloc, and more. After this investigation I reached out to the sqlite
authors, who were using malloc_usable_size in their internal allocator.
They did some profiling and determined that sqlite was faster with the
extra memory from malloc_usable_size, but that the cost of
malloc_usable_size itself undermined it, especially when there was no
additional memory to be gained. I also found that the scudo allocator was
intentionally tracking and returning the requested size rather than the
actual size to work around this sqlite behavior; so at least running on
platforms with the scudo allocator, they were paying the cost for no real
benefit.
The specific problem case occurred when I needed to allocate something
while parsing; unfortunately it was just slightly over half of of the
nearest size class in the underlying allocator, so nearly half the
allocated space was wasted. It happened to me again recently when I found
that something was requesting a power-of-2 sized allocation, which an
intermediate allocator was adding a small header to, and that header made
it just barely larger than the normal size class, resulting in bumping up
to the next size and wasting a bunch of memory. In both cases I had a
productive use for that memory (first was a bump allocator; second was
serializing into a buffer of bytes).
>
> If it is adopted, we would probably just have these functions all be
> thin wrappers for malloc that report that the size obtaned is exactly
> what you requested.
>
That's a valid implementation and the API is designed to permit it, to
avoid forcing implementations to expose details they would rather not
(unlike malloc_usable_size).
>
> Aside from that:
>
> 1. The "alloc_result_t" approach is particularly ugly and
> anti-idiomatic for C. Returning a void * pointer and taking a size_t *
> argument for a location to store the amount actually obtained would be
> a lot more idiomatic and discourage misuse.
>
> 2. The proposed free_sized and free_aligned_sized functions seem
> completely useless. As they have undefined behavior if the size and
> alignment you pass to them are not correct, they offer no advantage
> over just calling free, but make things much more error-prone.
>
These were already added to the standard in C23; the proposal just makes
some modifications to them to describe their interactions with the new apis.
>
> Overall, I would urge the committee to reject this whole proposal.
>
I'll relay that feedback to the mailing list, thank you. I take it you
would also be opposed to standardizing a version of malloc_usable_size?
Someone else proposed that in
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3869.pdf
>
> Rich
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
