on Wed, 24 May 2023 17:31:34 -0400 you (Rich Felker ) 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. 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? Jₑₙₛ -- :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Université de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: :: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::