now to the bit interfaces in the new header stdbit.h on Thu, 4 May 2023 17:53:57 +0200 you (Jₑₙₛ Gustedt ) wrote: > They are required for the three usual wide unsigned integer types. The > type-generic interface is supposed to work for all wide standard and > extended integer types (not including `_BitInt(N)` for weird `N`). So > the most natural here would be to add functions for the 128 bit > types. Also the generic code that just dispatches inline function > pointers is much easier and clearer. `_Generic` for function or macro > calls (in contrast to just function pointers) is much nastier, because > all branches must be valid C and should not drown us in > false-positives. So for the moment I kept it like that with inline function interfaces. To support the 128 bit types I did the following: - added internal interfaces that work with two 64 bit integers - added application side interfaces for `__int128` types - added application side interfaces for `_BitInt(128)` types The latter two are never part of musl itself, but only produced in the application as `static inline` interfaces that refer to the ones that work with two 64 bit numbers (and may tail call into these). So if the application compiler knows how to deal with `__int128` (very likely on 64 bit archs) or `_BitInt(128)` (very likely with C23 compilers) they can rely on the necessary infrastructor within musl, regardles with which compiler musl was compiled. Thanks Jₑₙₛ -- :: ICube :::::::::::::::::::::::::::::: deputy director :: :: Université de Strasbourg :::::::::::::::::::::: ICPS :: :: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus :: :: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 :: :: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::