Date: Thu, 25 May 2023 08:57:51 -0400 From: Rich Felker <dalias@...c.org> To: Jₑₙₛ Gustedt <jens.gustedt@...ia.fr> Cc: musl@...ts.openwall.com Subject: Re: [C23 new stdlib 1/4] C23: add the new interfaces free_sized and free_aligned_sized for stdlib.h On Thu, May 25, 2023 at 11:38:06AM +0200, Jₑₙₛ Gustedt wrote: > > on Wed, 24 May 2023 17:31:34 -0400 you (Rich Felker <dalias@...c.org>) > wrote: > > > These really should be in a separate file or files calling free() not > > __libc_free, since if free has been replaced, they should call that, > > not the libc-internal one. (Imagine a program linked or LD_PRELOADed > > with an alternate malloc implementation that's not C23-aware.) > > ok > > > Optionally, they could also evaluate the predicate to determine if > > malloc has been replaced, and if not, do the actual check. The > > alignment check is trivial and malloc-agnostic. The size check would > > require adding a libc-internal way to access malloc_usable_size. But > > this can all be done later if desired. > > I don't think these interfaces are about checking consistency. They > don't provide any reasonable means to return an error. In the contrary > they are meant to provide more efficient implementations for the > feature if the correct size is used. Otherwise, the behavior is just > undefined. My understanding was that, by having it be UB to call them with wrong size or alignment, they create an opportunity for the implementation to harden by trapping on inconsistency. This is a lot more valuable than whatever marginal performance advantage they might give (which is none for musl's mallocng or oldmalloc, anyway). > The first question to be would be if we want to offer that > functionality for musl's allocator. (I don't feel that I know enough > to do that.) The second question is, do we want to allow alternate > malloc implementations to provide replacements for this? Then we > should perhaps have these new interfaces as weak symbols? Weak symbols aren't the way to achieve that. They might be ~a way~ in some cases, but probably not a good one. What we use weak symbols for in musl is to allow stub implementations for the pattern "B needs to do something to interact with A if A was linked, but can skip that if A was not linked" without having B pull in A as a dependency. For static linking, just having the functions in separate TUs automatically gives the property of being able to provide a replacement (but there also has to be a contract to allow replacement; the malloc subsystem is the only thing for which we have such a contract, as an extension). For dynamic linking, weak is irrelevant/ignored, and interposition (by design) approximates the static linking behavior. Since redefining standard functions is UB, we link with most symbol references inside libc.so bound at libc.so link time, so that calls don't have to go through GOT lookup or PLT. But for malloc, we suppress that via the dynamic.list file. Strictly speaking, any new functions added to malloc should be added to dynamic.list so they're kept interposable. Since we're not planning to call any of these from within libc, it doesn't make any difference, but I'd still add them there for completeness and future-proofing. Rich
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.