On Fri, Jul 10, 2026 at 01:58:29PM +0200, Martin Uecker wrote:
> I would not allow generic VLA-type _BitInt and only allow it
> va_arg and certain other scenarios. But how exactly would need
> to be worked out, e.g. using the va_arg_ptr we discussed
> previously
>
> void *bitintptr = va_arg_ptr(ap, _BitInt(n));
>
> or by making the result of va_arg an lvalue
>
> void *bitintptr = &va_arg(ap, _BitInt(n)),
The above is what the proposal does effectively under the hood,
before passing it to the stdc_bitint_store macro.
The reason I didn't want to expose it is the question of the
lifetime of the object pointed to by that pointer.
If va_list is void */char *, then all ... arguments are passed
on the stack and so the pointed to object will have the lifetime
of the whole function. But if the ABI needs to store some of
the hard registers used for argument passing somewhere somewhere
into the stack, and especially if ABI allows partial passing of
_BitInt (say first word or two passed in registers, rest on the stack),
then one actually doesn't have a contiguous chunk of memory that contains
it, so va_arg_ptr or &va_arg would effectively need to create a temporary
which holds the whole value. Now, if everything is hidden under a single
macro, it is an implementation detail, but when it is exposed, for how long
that temporary is in scope?
> One could also possibly allow them in pointer types
>
> _BitInt(n) *ptr = va_arg(ap, _BitInt(n)*);
>
>
> All this seems relatively unproblematic to me and would essentially
> be just nicer syntax and better type safety for what you are proposing.
But then the question is if one can dereference *ptr or just pass it to
some macro/function to decode it.
OT, I've mailed Daniel to request paper numbers for these on Tuesday, but
haven't heard back yet, how long does that usually take (given the deadline on
17th)?
Jakub
