Re: Draft C2Y _BitInt related proposals

Georg-Johann Lay <[email protected]> Wed, 8 Jul 2026 19:57:36 +0200
Newsgroups gmane.comp.lib.glibc.alpha,gmane.comp.gcc.devel
Message-ID <[email protected]>
Am 07.07.26 um 16:47 schrieb Jakub Jelinek via Gcc:
> Hi!
> 
> As I wrote earlier, I'd like to see _BitInt I/O support in
> *printf*/*scanf* and extending support of _BitInt in stdbit.h
> in C2Y.
> 
> For those I wrote drafts of possible C2Y papers:
> https://jakubjelinek.github.io/wg14/va_arg_bitint.html
> https://jakubjelinek.github.io/wg14/stdbit_bitint.html
> 
> I'd appreciate any comments on this.
> Haven't tried to acquire paper numbers for these yet.
> 
> 	Jakub

The proposal mentions qualifiers, e.g in the section below:


> The va_arg macro expands to an expression that has the specified type and the value of the next argument in the call. The parameter ap shall have been initialized by the va_start or va_copy macro (without an intervening invocation of the va_end macro for the same ap). Each invocation of the va_arg macro modifies ap so that the values of successive arguments are returned in turn. The behavior is undefined if there is no actual next argument. The parameter type shall be an object type name. If type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined, except for the following cases:
> — both types are pointers to qualified or unqualified versions of compatible types;
> — both types are pointers to qualified or unqualified versions of bit-precise integer types;
> — one type is compatible with a signed integer type, the other type is compatible with the corresponding unsigned integer type, and the value is representable in both types;
> — one type is pointer to qualified or unqualified void and the other is a pointer to a qualified or unqualified character type;
> — or, the type of the next argument is nullptr_t and type is a pointer type that has the same representation and alignment requirements as a pointer to a character type.265)

There is a proposal N3795 to add (intrinsic) named address spaces 
(qualifiers) to C2Y:

https://www.open-std.org/jtc1/sc22/WG14/www/docs/n3795.pdf

So when N3795 or something similar goes in, then the text above should 
make clear that it doesn't mean qualifiers that are associated to a 
named address space?

Johann