[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230525125751.GG4163@brightrain.aerifal.cx>
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.
