When trying to compile this code
#include <stdarg.h>
void bar_ptr(int n, va_list *pvl) {
// do va_arg stuff here
}
void bar(int n, va_list vl) {
va_list *pvl = &vl; // error here
bar_ptr(n, pvl);
}
void foo(int n, ...) {
va_list vl;
va_list *pvl = &vl; // fine here
va_start(vl, n);
bar(n, vl);
va_end(vl);
}
int main() {
foo(3, 1, 2, 3);
return 0;
}
the GCC compiler prints a warning about initialization from incompatible pointer type in the bar function. The identical statement is fine in foo.
It seems that the type of an agument of type va_list is not a va_list. This can be tested easily with a static assertion like
_Static_assert(sizeof(vl) == sizeof(va_list), "invalid type");
in the bar function. With GCC, the _Static_assert fails. The same can be tested also in C++ with declytpe and std::is_same.
I would like to take the address of the va_list vl argument of bar, and pass it as argument of bar_ptr, to do thinks like the one described in this thread. On the other hand, it is fine to call bar_ptr(n, pvl) directly from main, replacing bar(n, vl).
According to the footnote 253 of the C11 final draft,
It is permitted to create a pointer to a va_list and pass that
pointer to another function
Why this cannot be done if va_list is defined as argument of the function, and not in the function body?
Workaround:
Even if this does not answer the question, a possible workaround is to change the content of bar by using a local copy of the argument created with va_copy:
void bar(int n, va_list vl) {
va_list vl_copy;
va_copy(vl_copy, vl);
va_list *pvl = &vl_copy; // now fine here
bar_ptr(n, pvl);
va_end(va_copy);
}
va_list is permitted by the standard to be an array, and often it is.
That means va_list in a function argument gets adjusted to a pointer to whatever va_list's internal first element is.
The weird rule (7.16p3) regarding how va_list gets passed basically accommodates the possibility that va_list might be of an array type or of a regular type.
I personally wrap va_list in a struct so I don't have to deal with this.
When you then pass pointers to such a struct va_list_wrapper, it's basically as if you passed pointers to va_list, and then footnote 253 applies which gives you the permission to have both a callee and a caller manipulate the same va_list via such a pointer.
(The same thing applies to jmp_buf and sigjmp_buf from setjmp.h. In general, this type of array to pointer adjustment is one of the reasons why array-typed typedefs are best avoided. It just creates confusion, IMO.)
Another solution (C11+ only):
_Generic(vl, va_list: &vl, default: (va_list *)vl)
Explanation: if vl has type va_list, then va_list isn't an array type and just taking the address is fine to get a va_list * pointing to it. Otherwise, it must have array type, and then you're permitted to cast a pointer to the first element of the array (whatever type that is) to a pointer to the array.
Related
I have a function which looks like
void demo_function_v(const char * mask, va_list ap)
{
for (; *mask; mask++) {
// get one or more args from ap, depending on *mask
}
}
This runs on a AVR system which has different access techniques for the flash memory. In order to duplicate this function, I'd like to extract the main part of it:
void demo_function_1char(char mask, va_list ap)
{
// get one or more args from ap, depending on mask
}
void demo_function_v(const char * mask, va_list ap)
{
for (; *mask; mask++) {
demo_function_1char(*mask, ap)
}
}
Alas, this is not guaranteed to work, as
The object ap may be passed as an argument to another function; if that function invokes the va_arg macro with parameter ap, the value of ap in the calling function is indeterminate.
And this is true - on x86, it doesn't work, on x64, it does. If it works on AVR, I'll be able to test tomorrow. But I'd rather not rely on this if it is described as "indeterminate" (which is supposedly a kind of UB).
Thus, I'd like to go another track:
void demo_function_1char(char mask, va_list * pap)
{
// get one or more args from *pap, depending on mask
}
void demo_function_v(const char * mask, va_list ap)
{
for (; *mask; mask++) {
demo_function_1char(*mask, &ap)
}
}
Is this supposed to work, or will I shoot my foot this way as well?
The C99 standard has the following footnote clarifying this:
It is permitted to create a pointer to a va_list and pass that pointer to another function, in which case the original function may make further use of the original list after the other function returns.
I believe that behavior was also the intent in C90 even if the standard didn't note it. The C90 rationale document does have this to say:
The va_list type is not necessarily assignable. However, a function can pass a pointer to its initialized argument list object, as noted below.
...
va_start must be called within the body of the function whose argument list is to be traversed. That function can then pass a pointer to its va_list object ap to other functions to do the actual traversal. (It can, of course, traverse the list itself.)
Making it pretty clear, I think, that accessing the va_list object through a pointer acts as you'd expect (that the va_list state is being maintained in the object instance that the address was taken from), even if it doesn't explicitly state that the original va_list object will pick up where the pointer usage left off. For it to not work this way, pointers to va_list objects would have to behave differently than pointers to other C objects.
I have a function which accepts variable number of argumets of different data types using ellipsis. I wanted to know is there any way by which I can get each of them. If not all, atleast separate a particular argument (either first or last parameter) from the rest and va_list from the remaining.
Declaration goes like this :
int foo (char *a , ...)
Usage :
result = foo ("I'm a String",2,34.56,"one more String",2323232323);
result = foo ("I'm another String",3,"again one more String",34.62,111111111);
So, here(usage 1) I want to remove parameter '2' from the va_list got and make another va_list with the rest. Function declaration is flexible, and can be changed accordingly.
Thanks in advance
Note that variable argument functions must have a way to determine the types of the arguments in the ellipsis (va_list). The printf() and scanf() families of functions have the format string to specify the types; the open() system call has an optional third argument but it is always an int; and the execl() function takes a list of arguments all of the same type, char *, terminated by a NULL pointer).
If you have a function:
void foo_tail(va_list args);
You can write your function foo() as:
int foo(char *a, ...)
{
va_list args;
va_start(args, a);
int arg2 = va_arg(args, int);
foo_tail(args);
va_end(args);
return arg2;
}
This achieves what the question asks for:
remove parameter '2' from the va_list got and make another va_list with the rest.
Whether foo_tail() can work out what to do with the va_list it is given is a separate discussion; it is not clear how it would distinguish between the two calls shown in the question, but to handle both, that information would have to be made available somehow. A variable list of mixed types as shown is very problematic.
When you use va_arg the argument you get is actually removed from the va_list. So the rest of the arguments are already in your va_list.
However, you can not, say, get an arbitrary argument from the list. They have to be taken in order. You also must know the actual types of the arguments you're getting.
Consider the following test case:
#define _GNU_SOURCE
#include <stdio.h>
#include <stdarg.h>
void test(char **outa, char **outb, const char* fstra, const char* fstrb, ...) {
va_list ap;
va_start(ap, fstrb);
vasprintf(&outa, fstra, ap);
vasprintf(&outb, fstrb, ap);
va_end(ap);
}
int main(void) {
char *a, *b;
test(&a, &b, "%s", " %s\n", "foo", "bar");
/* ... */
}
The intent here is that the test() function takes two format strings and a list of parameters for both of them. The first format string is supposed to 'eat' as many arguments it needs, and the remaining ones are supposed to be used for the second format string.
So, the expected result here would be foo & bar and that's what I get with glibc. But AFAICS the machine running codepad (guess some *BSD it is), gives foo & foo and my guess is that it uses va_copy() on the argument list.
I guess I'm hitting an undefined (and ugly) behavior here; so the question is: is there a way to achieve double-format-string printf() without reimplementing it from scratch? And is there a nice way to check that behavior using autoconf without using AC_RUN_IFELSE()?
I guess some quick method of scanning format-string for the number of arguments to be consumed could work here as well (+va_copy()).
When you call one of the v*printf functions, this uses va_arg which means the value of ap is indeterminate on return.
The relevant bit lies in section 7.19.6.8 The vfprintf function in C99, which references the footnote:
As the functions vfprintf, vfscanf, vprintf, vscanf, vsnprintf, vsprintf, and vsscanf invoke theva_argmacro, the value ofargafter the return is indeterminate.
This has survived to the latest draft of C1x I have as well, so I suspect it's not going to change quickly.
There is no portable way to do what you're attempting using the higher-level v*printf functions although you could resort to using the lower level stuff.
The standard is very clear in that a called function using va_arg on a va_list variable renders it indeterminate in the caller. From C99 7.15 Variable Arguments <stdarg.h>:
The object ap may be passed as an argument to another function; if that function invokes the va_arg macro with parameter ap, the value of ap in the calling function is indeterminate and shall be passed to the va_end macro prior to any further reference to ap.
However, the value of ap when using va_arg on it within a single function is determinate (otherwise the whole variable arguments processing would fall apart). So you could write a single function which processed both format strings in turn, with these lower-level functions.
With the higher level stuff (as per the footnote), you are required to va_end/va_start to put the ap variable back in a determinate state and this will unfortunately reset to the start of the parameter list.
I'm not sure how much of a simplification your provided example code is but, if that's close to reality, you can acheive the same result by just combining the two format strings beforehand and using that to pass to vprintf, something like:
void test(const char* fstra, const char* fstrb, ...) {
char big_honkin_buff[1024]; // Example, don't really do this.
va_list ap;
strcpy (big_honkin_buff, fstra);
strcat (big_honkin_buff, fstrb);
va_start(ap, big_honkin_buff);
vprintf(big_honkin_buff, ap);
va_end(ap);
}
As the other answer already states, passing ap to a v*() function leaves ap in an undetermined state. So, the solution is to not depend on this state. I suggest an alternative workaround.
First, initialize ap as normal. Then determine the length of the first formatted string using vsnprintf(NULL, 0, fstra, ap). Concatenate the format strings, reinitialize ap, and split the output using the predetermined length of the first formatted string.
It should look something like the following:
void test(const char* fstra, const char* fstrb, ...) {
char *format, *buf;
char *a, *b;
int a_len, buf_len;
va_list ap;
va_start(ap, fstrb);
a_len = vsnprintf(NULL, 0, fstra, ap);
va_end(ap);
asprintf(&format, "%s%s", fstra, fstrb);
va_start(ap, fstrb);
buf_len = vasprintf(&buf, format, ap);
va_end(ap);
free(format);
a = malloc(a_len + 1);
memcpy(a, buf, a_len);
a[a_len] = '\0';
b = malloc(buf_len - a_len + 1);
memcpy(b, buf + a_len, buf_len - a_len);
b[buf_len - a_len] = '\0';
free(buf);
}
As also discussed in the other answer, this approach does not separate positional printf-style placeholders ("%1$s. I repeat, %1$s."). So the documentation for the interface should clearly state that both format strings share the same positional placeholder namespace—and that if one of the format strings uses positional placeholders then both must.
To complete the other answers, which are correct, a word about what happens in common implementations.
In 32bit Linux (and I think Windows too), passing the same ap to two functions actually works.
This is because the va_list is just a pointer to the place on the stack where the parameters are. v*rintf functions get it, but don't change it (they can't, it's passed by value).
In 64bit Linux (don't know about Windows), it doesn't work.
va_list is a struct, and v*printf gets a pointer to it (because actually it's an array of size 1 of structs). When arguments are consumed, the struct is modified. So another call to v*printf will get the parameters not from the start, but after the last one consumed.
Of course, this doesn't mean you should use a va_list twice in 32bit Linux. It's undefined behavior, which happens to work in some implementations. Don't rely on it.
Anyone have a reference for the representation of va_list in the x86_64 ABI (the one used on Linux)? I'm trying to debug some code where the stack or arguments seem corrupt and it would really help to understand what I'm supposed to be seeing...
The x86-64 System V ABi doc may help. It's a reference, albeit lightweight.
The Variable Argument List reference starts on page 54, then it goes on, page 56-57 documents va_list:
The va_list Type
The va_list type is an array containing a single element of one structure containing the necessary information to implement the va_arg macro. The C definition of va_list type is given in figure 3.34.
Figure 3.34: va_list Type Declaration
typedef struct {
unsigned int gp_offset;
unsigned int fp_offset;
void *overflow_arg_area;
void *reg_save_area;
} va_list[1];
The va_start Macro
The va_start macro initializes the structure as follows:
reg_save_area The element points to the start of the register save area.
overflow_arg_area This pointer is used to fetch arguments passed on the stack. It is initialized with the address of the first argument passed on the stack, if any, and then always updated to point to the start of the next argument on the stack.
gp_offset The element holds the offset in bytes from reg_save_area to the place where the next available general purpose argument register is saved. In case all argument registers have been exhausted, it is set to the value 48 (6 * 8).
fp_offset The element holds the offset in bytes from reg_save_area to the place where the next available floating point argument register is saved. In case all argument registers have been exhausted, it is set to the value 304 (6 * 8 + 16 * 16).
It turns out the problem was gcc's making va_list an array type. My function was of the signature:
void foo(va_list ap);
and I wanted to pass a pointer to ap to another function, so I did:
void foo(va_list ap)
{
bar(&ap);
}
Unfortunately, array types decay to pointer types in function argument lists, so rather than passing a pointer to the original structure, I was passing a pointer to a pointer.
To work around the problem, I changed the code to:
void foo(va_list ap)
{
va_list ap2;
va_copy(ap2, ap);
bar(&ap2);
va_end(ap2);
}
This is the only portable solution I could come up with, that accounts for both the possibility that va_list is an array type and the possibility that it's not.
In i386 architecture, the va_list is a pointer type. However, in AMD64 architecture, it is an array type. What is the difference? Actually, if you apply an & operation to a pointer type, you will get the address of this pointer variable. But no matter how many times you apply & operation to an array type, the value is the same, and is equal to the address of this array.
So, what should you do in AMD64? The easiest way to pass variable of va_list in a function is just passing it with no * or & operator.
For example:
void foo(const char *fmt, ...) {
va_list ap;
int cnt;
va_start(ap, fmt);
bar(fmt, ap);
va_end(ap);
return cnt;
}
void bar(const char *fmt, va_list ap) {
va_arg(ap, int);
//do something
test(ap);
}
void test(va_list ap) {
va_arg(ap, int);
//do something
}
It just works! And you don't need to worry about how many arguments you have got.
Suppose I have a function which takes variadic arguments (...) or a va_list passed from another such function. The main logic is in this function itself (let's call it f1), but I want to have it pass the va_list to another function (let's call it f2) which will determine the next argument type, obtain it using va_arg, and properly convert and store it for the caller to use.
Is it sufficient to pass a va_list to f2, or is it necessary to pass a pointer to va_list. Unless va_list is required to be an array type or else store its position data at the location the va_list object points to (rather than in the object itself), I can't see how passing it by value could allow the calling function (f1) to 'see' the changes the called function made by va_arg.
Can anyone shed light on this? I'm interested in what the standard requires, not what some particular implementation allows.
It looks like you'll need to pass a pointer to the va_list. For more info, see the C99 standard document section 7.15.In particular, bullet point 3 states:
The object ap may be passed as an argument to
another function; if that function invokes the va_arg macro with parameter ap, the
value of ap in the calling function is indeterminate and shall be passed to the va_end
macro prior to any further reference to ap
[my italics]
Edit: Just noticed a footnote in the standard:
215) It is permitted to create a pointer to a va_list and pass that pointer to another function, in which
case the original function may make further use of the original list after the other function returns
So you can pass a pointer to the va_list and do va_arg(*va_list_pointer) in the called function.
In my understanding, you're supposed to pass the va_list directly (not a pointer to it). This seems to be supported by comp.lang.c:
"A va_list is not itself a variable argument list; it's really sort of a pointer to one. That is, a function which accepts a va_list is not itself varargs, nor vice versa. "
I find the texts quite ambiguous on this question. The simplest is perhaps to look in the standard how predefined functions with va_list are supposed to receive it, e.g vsnprintf. And this is clearly by value and not by reference.
You should pass a pointer to a va_list if you want to use it in a subfunction and then not have to immediately pass it to va_end afterwards. From C99:
It is permitted to create a pointer to a va_list and pass that pointer to another function, in which case the original function may make further use of the original list after the other function returns.
The standard allows this, however, on some 64-bit platforms where va_list is an array type, this does not work. As the address of an array is the same as the address of the first element of the array, passing a pointer to the va_list will segfault upon calling va_arg with that pointer to va_list as an argument.
A way to get around this is by receiving the va_list as an unconventional argument name (usually suffixed with one or more underscores) and then creating a new local va_list, like so:
#include <stdarg.h>
int vfoo(va_list ap_)
{
int ret;
va_list ap;
va_copy(ap, ap_);
ret = vbar(&ap);
/* do other stuff with ap */
va_end(ap);
return ret;
}
This is the approach I use in my vsnprintf implementation to call other functions from it for formatting.
Functions in standard C library pass va_list element itself (man 3 vprintf):
#include <stdarg.h>
int vprintf(const char *format, va_list ap);
int vfprintf(FILE *stream, const char *format, va_list ap);
int vsprintf(char *str, const char *format, va_list ap);
int vsnprintf(char *str, size_t size, const char *format, va_list ap);
Passing a pointer to va_list works fine in 32 bit system. You can even fetch one parameter a time in the sub-routine.
But it doesn't seem to work in 64 bit system, will produce a segment fault at va_arg().