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
