who implements C23 <stdbit.h> and <stdckdint.h>?

[enh-google]

Are these like <stdnoreturn.h>, or like <stdio.h>? I don't care, but it would be silly for me to add them to bionic if Clang will just provide its own anyway :-)

(the Clang <tgmath.h> in particular makes me think this might be one you'd rather do yourselves?)

[AaronBallman]

I think <stdchkdint.h> will likely come from the C standard library, but I can see <stdbit.h> going either way (it's part of the freestanding requirements, but we're leaning more and more towards the user having to supply their own freestanding-compatible libc so that our headers basically only provide macros.

CC @jyknight @zygoloid @efriedma-quic @rjmccall for further opinions

[llvmbot]

@llvm/issue-subscribers-c2x

[enh-google]

I think <stdchkdint.h> will likely come from the C standard library, but I can see <stdbit.h> going either way

did you mean that, or did you mean the opposite? <stdckdint.h> is macro-only, whereas <stdbit.h> says "It is unspecified whether any generic function declared in <stdbit.h> is a macro or an identifier declared with external linkage".

tbh, i think these are only useful as macros, because the whole point is that they're all just builtins that hopefully resolve to a single instruction. which is why it seems like maybe the compilers (who own the builtins) should own the headers too?

(i'm happy to contribute headers --- i'm interested in reducing duplication, not specifically about getting out of doing work myself :-) )

[efriedma-quic]

stdbit.h can't really be implemented as just a header because it's legal to take the address of some of the functions. (I mean, maybe you could do something tricky to make the implementations linkonce, but I don't think we want to.)

[MaskRay]

(other C vendors) @DimitryAndric @richfelker

[enh-google]

stdbit.h can't really be implemented as just a header because it's legal to take the address of some of the functions

doesn't the part of the standard i quoted above explicitly give us the latitude to not have them be real functions? "It is unspecified whether any generic function declared in <stdbit.h> is a macro or an identifier declared with external linkage."

[AaronBallman]

did you mean that, or did you mean the opposite? <stdckdint.h> is macro-only, whereas <stdbit.h> says "It is unspecified whether any generic function declared in <stdbit.h> is a macro or an identifier declared with external linkage".

Oh, you're right, stdchkdint.h is just macros; I thought there were functions in there.

stdbit.h can't really be implemented as just a header because it's legal to take the address of some of the functions

doesn't the part of the standard i quoted above explicitly give us the latitude to not have them be real functions? "It is unspecified whether any generic function declared in <stdbit.h> is a macro or an identifier declared with external linkage."

Agreed, I think we have that latitude here.

[efriedma-quic]

The standard says it's "unspecified whether any generic function declared in <stdbit.h> [...]". Note the word "generic"; I'm pretty sure the rule is only supposed to apply to the type-generic functions, and the non-generic functions follow the ordinary rules for standard library functions.

[AaronBallman]

The standard says it's "unspecified whether any generic function declared in <stdbit.h> [...]". Note the word "generic"; I'm pretty sure the rule is only supposed to apply to the type-generic functions, and the non-generic functions follow the ordinary rules for standard library functions.

Oh shoot, you're right Eli (sorry for waffling). The allowances in 7.1.4 don't save us (they're what obligate us to make the non-generic APIs be real functions at the end of the day).

[pirama-arumuga-nainar]

The consensus, IIUC, is that clang will provide <stdckdint.h> and the C standard library should provide <stdbit.h>. @ZijunZhaoCCK is working on adding stdckdint.h.

[AaronBallman]

I agree, that's the consensus here. And thank you to @ZijunZhaoCCK for looking into adding stdckdint.h!