Are there gotchas using varargs with reference parameters

Question

I have this piece of code (summarized)...

AnsiString working(AnsiString format,...)
{
    va_list argptr;
    AnsiString buff;

    va_start(argptr, format);
    buff.vprintf(format.c_str(), argptr);

    va_end(argptr);
    return buff;
}

And, on the basis that pass by reference is preferred where possible, I changed it thusly.

AnsiString broken(const AnsiString &format,...)
{
... the rest, totally identical ...
}

My calling code is like this:-

AnsiString s1, s2;
    s1 = working("Hello %s", "World");
    s2 = broken("Hello %s", "World");

But, s1 contains "Hello World", while s2 has "Hello (null)". I think this is due to the way va_start works, but I'm not exactly sure what's going on.

Answer 1

If you look at what va_start expands out to, you'll see what's happening:

va_start(argptr, format); 

becomes (roughly)

argptr = (va_list) (&format+1);

If format is a value-type, it gets placed on the stack right before all the variadic arguments. If format is a reference type, only the address gets placed on the stack. When you take the address of the reference variable, you get the address or the original variable (in this case of a temporary AnsiString created before calling Broken), not the address of the argument.

If you don't want to pass around full classes, your options are to either pass by pointer, or put in a dummy argument:

AnsiString working_ptr(const AnsiString *format,...)
{
    ASSERT(format != NULL);
    va_list argptr;
    AnsiString buff;

    va_start(argptr, format);
    buff.vprintf(format->c_str(), argptr);

    va_end(argptr);
    return buff;
}

...

AnsiString format = "Hello %s";
s1 = working_ptr(&format, "World");

or

AnsiString working_dummy(const AnsiString &format, int dummy, ...)
{
    va_list argptr;
    AnsiString buff;

    va_start(argptr, dummy);
    buff.vprintf(format.c_str(), argptr);

    va_end(argptr);
    return buff;
}

...

s1 = working_dummy("Hello %s", 0, "World");

Answer 2

Here's what the C++ standard (18.7 - Other runtime support) says about va_start() (emphasis mine) :

The restrictions that ISO C places on the second parameter to the va_start() macro in header <stdarg.h> are different in this International Standard. The parameter parmN is the identifier of the rightmost parameter in the variable parameter list of the function definition (the one just before the ...). If the parameter parmN is declared with a function, array, or reference type, or with a type that is not compatible with the type that results when passing an argument for which there is no parameter, the behavior is undefined.

As others have mentioned, using varargs in C++ is dangerous if you use it with non-straight-C items (and possibly even in other ways).

That said - I still use printf() all the time...

Answer 3

A good analysis why you don't want this is found in N0695

Answer 4

According to C++ Coding Standards (Sutter, Alexandrescu):

varargs should never be used with C++:

They are not type safe and have UNDEFINED behavior for objects of class type, which is likely causing your problem.

Answer 5

Here's my easy workaround (compiled with Visual C++ 2010):

void not_broken(const string& format,...)
{
  va_list argptr;
  _asm {
    lea eax, [format];
    add eax, 4;
    mov [argptr], eax;
  }

  vprintf(format.c_str(), argptr);
}

Answer 6

Side note:

The behavior for class types as varargs arguments may be undefined, but it's consistent in my experience. The compiler pushes sizeof(class) of the class's memory onto the stack. Ie, in pseudo-code:

alloca(sizeof(class));
memcpy(stack, &instance, sizeof(class);

For a really interesting example of this being utilized in a very creative way, notice that you can pass a CString instance in place of a LPCTSTR to a varargs function directly, and it works, and there's no casting involved. I leave it as an exercise to the reader to figure out how they made that work.