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
