Re: Draft C2Y _BitInt related proposals

On Tue, Jul 07, 2026 at 04:25:10PM +0000, Joseph Myers wrote:
> > 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

Thanks for the comments.

> generic_limb_type should probably be required to be an unsigned type; the 
> descriptions don't work with it as a signed type.  Since the terminology 
> was changed so that bool isn't counted as an unsigned integer type any 
> more, that would then mean "other than bool" is no longer needed.

In the actual posted patch it was supporting even signed types, but sure,
requiring unsigned types is reasonable.

> Various editorial fixes: "pointed by" should be "pointed to by" (six 
> times).  "from object" should be "from the object" (twice), "from array" 
> should be "from the array", "into array" should be "into the array".

Will fix.

> The proposed feature wouldn't actually allow for implementing scanf in 
> standard C because of the need to pass the right pointer-to-_BitInt type 
> to va_arg there (though this isn't very likely to be an issue in practice 
> with scanf implementation, and POSIX has an XSI-marked allowance for 
> mixing arbitrary pointer types in va_arg, in support of use of %n$ in 
> scanf).

Would it be ok to add an exception for this in 7.16.2.2?  If arbitrary
pointer va_arg compatibility is not feasible for historic reasons, perhaps
just
- both types are pointers to qualified or unqualified versions of
  bit-precise integer types;
?
I'd hope that nobody who implements _BitInt in this decade decides to take
the liberty and pass _BitInt(1) * differently from _BitInt(2) * or
_BitInt(293) *.

> > https://jakubjelinek.github.io/wg14/stdbit_bitint.html
> 
> Maybe remark in the introduction that there is also the _Generic technique 
> (pointed out by Martin, I think) for determining _BitInt widths even with 
> a very large range (match on types such as _BitInt(sizeof(arg)*8), 
> _BitInt(sizeof(arg)*8-1), ..., _BitInt(sizeof(arg)*8-63), depending on the 
> details of how the ABI determines _BitInt size and with appropriate 
> handling to cover the top and bottom of the range of possible widths).

Ah, smart, those surely a little bit implementation dependent (but guess
going down to -127 would handle all currently supported ones).

> And I think the wording in various places could just say "an unsigned 
> integer type" without needing bullet points for the different kinds of 
> such types any more.

Ok.

	Jakub