Question

During an interview I was requested (among other things) to implement the following function:

int StrPrintF(char **psz, const char *szFmt, ...);

similar to sprintf, except instead of the already-allocated storage the function must allocate it itself, and return in the *psz variable. Moreover, *psz may point to an already-allocated string (on the heap), which may potentially be used during the formatting. Naturally this string must be free by the appropriate means.

The return value should be the length of the newly created string, or negative on error.

This is my implementation:

int StrPrintF(char **psz, const char *szFmt, ...)
{
    va_list args;
    int nLen;

    va_start(args, szFmt);

    if ((nLen = vsnprintf(NULL, 0, szFmt, args)) >= 0)
    {
        char *szRes = (char*) malloc(nLen + 1);
        if (szRes)
            if (vsnprintf(szRes, nLen + 1, szFmt, args) == nLen)
            {
                free(*psz);
                *psz = szRes;
            }
            else
            {
                free(szRes);
                nLen = -1;
            }
        else
            nLen = -1;
    }

    va_end(args);
    return nLen;
}

The question author claims there’s a bug in this implementation. Not just a standard violation that may fail on particular esoteric systems, but a “real” bug, which by chance may fail on most systems.

It’s also not related to usage of int instead of memory-capability-suited type, such as size_t or ptrdiff_t. Say, the strings are of “reasonable” size.

I really have no clue of what the bug could be. All the pointer arithmetic is ok IMHO. I even don’t assume that two consequent invocations of vsnprintf produce the same result. All the variadic-handling stuff is also correct IMHO. va_copy is not needed (it’s the responsibility of the callee that uses va_list). Also on x86 va_copy and va_end are meaningless.

I’ll appreciate if someone can spot the (potential) bug.

EDIT:

After checking out the answers and comments – I’d like to add some notes:

• Naturally I’ve built and run the code with various inputs, including step-by-step in debugger, watching the variables state. I’d never ask for help without trying things myself first. I saw no sings of problems, no stack/heap corruption, etc. Also I’ve run it in debug build, with the debug heap enabled (which is intolerant to heap corruption).
• I assume that the function is called with valid parameters, i.e. psz is a valid pointer (not to confuse with *psz), szFmt is a valid format specifier, and all the variadic parameters are evaluated and correspond to the format string.
• Calling free with NULL pointer is ok according to the standard.
• Calling vsnprintf is ok with NULL pointer and size=0. It should return the resulting string length. MS-version, though not fully standard-compliant, does the same in this specific case.
• vsnprintf won’t exceed the specified buffer size, including the 0-terminator. Means – it does not always places it.
• Please put the coding style aside (if you don’t like it – fine with me).

Answer 1

va_copy is not needed (it’s the responsibility of the callee that uses
va_list)

Not quite right. I didn’t find any such requirement for vsnprintf in the C11 standard. It does say this in a footnote:

As the functions vfprintf, vfscanf, vprintf, vscanf, vsnprintf,
vsprintf, and vsscanf invoke the va_arg macro, the value of arg after
the return is indeterminate.

When you call vsnprintf, the va_list can be passed by value or by reference (it’s an opaque type for all we know). So the first vsnprintf can actually modify va_list and ruin things for the second. The recommended approach is to make a copy using va_copy.

And indeed, according to this article it doesn’t happen that way on x86 but it does on x64.