Re: Draft C2Y _BitInt related proposals

Am Freitag, dem 10.07.2026 um 14:14 +0200 schrieb Jakub Jelinek via Gcc:
> 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.  

On the other hand, for large _BitInts one might avoid
unnecessary copies *if* it is continuously on the stack.
Are there ABIs that do this differently?

> 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?

Maybe it could just the block as if the va_arg creates
a compound literals.   I understand your argument though.

> 
> > 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.

If one allows dereferencing it in general than one ends up
with lvalues of variable _BitInt type.  While I think this
would be useful, this would certainly make things a lot more
complicated.   But even without beind allowed to dereference
it, I think this would be useful because one could copy it
generically.

_BitInt(n) *ptr = va_arg(ap, typeof(ptr));

char buf[sizeof *ptr]
memcpy(buf, ptr, sizeof *buf);

or something like this.  Perhaps one could also allow dereferencing
on the RHS of an assignment.

> 
> 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)?

I would expect this to be processed on Sunday.

Martin