appending last argument to (wrap(ed)) variadic function call

[Florian Weimer]

* Alexandre François Garreau:

> Le lundi 24 février 2020, 12:20:22 CET Florian Weimer a écrit :
>> * Alexandre François Garreau:
>> > I want to wrap a call to a variadic function (which have both a really
>> > variadic version, and one taking a va_list as argument), and let its
>> > last argument be fixed by this wrapper (accordingly modifying the
>> > fixed argument that specify about the variable arguments and their
>> > types)… how can I do that?
>> 
>> You cannot access the last argument unless you know the types of all the
>> preceding arguments.  A GCC extension, __builtin_va_arg_pack_len,
>> allows you to get the number of arguments, but if they have unknown
>> types, that does not really help to solve this problem.
>
> But I don’t want to access it but to fix/set it…

Sorry, I don't understand.  Replacing or even adding an argument
requires knowledge of the location of the argument.

> Also I have access to the format string, so theorically I could know all 
> the types and the number of arguments… but anyway I’d end with a va_arg at 
> some point, and no other way to pass a variable number of argument… so no 
> way to “concat” two sequences of args… va_list stays pretty opaque to me 
> (and as it is unspecified, I wouldn’t expect it to be portable anyway…).

va_list simply does not have this kind of type information.  It's
basically a forward iterator, and in order to advance it, you need to
supply the correct type via va_arg.  It's also not possible to construct
a va_list from scratch, you can only get a tail of an argument list that
was already present in the program.  (There are libraries such as libffi
which get around this.)

The easiest way to achieve what you want is to supply a fix hint to the
actual implementation, which then applies the change at the right point
during the va_list iteration.

> Are there a lot of bare C features which are implemented internally with 
> C++ inside glibc?

There are none today.  On the technical side, bootstrapping a
cross-toolchain (binutils, GCC, glibc) is a concern, along with compile
time increases when building glibc.  And of course there are many
non-technical concerns.

Thanks,
Florian