[musl] stdbit.h

["Jₑₙₛ Gustedt" <jens.gustedt@inria.fr>]

[-- Attachment #1: Type: text/plain, Size: 1841 bytes --]

now to the bit interfaces in the new header stdbit.h

on Thu, 4 May 2023 17:53:57 +0200 you (Jₑₙₛ Gustedt
<jens.gustedt@inria.fr>) 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 ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]