is it safe to use va_copy on windows

Question

I have gone through the link https://devblogs.microsoft.com/oldnewthing/20131114-00/?p=2663 for potential pitsfalls using va_list

And below code segment from the same link specifies not to use va_list in manner shown because a va_list is not directly copyable.

BOOL FormatWithFallbackLanguage(
    DWORD dwMessageId, PCTSTR pszBuffer, SIZE_T cchBuffer, va_list ap)
{
 va_list apOriginal = ap;
 // Format from the user's preferred language.
 DWORD cchResult = FormatMessage(
               FORMAT_MESSAGE_FROM_HMODULE,
               g_hinst, dwMessageId, g_preferredLangId,
               pszBuffer, cchBuffer, &ap);
 // If that didn't work, then use the fallback language.
 if (cchResult == 0) {
  cchResult = FormatMessage(
               FORMAT_MESSAGE_FROM_HMODULE,
               g_hinst, dwMessageId, g_fallbackLangId,
               pszBuffer, cchBuffer, &apOriginal);
 }
 return cchResult != 0;
}

The article in the link suggesting to use va_copy for above coding scenario. However on windows, in the header file stdarg.h , the va_copy doesn't seem to be doing anything

#define va_copy(destination, source) ((destination) = (source))

My question is that whether its safe to use va_copy in windows for va_list ? If yes, why and if not then whats the way forward?

Answer 1

You're not supposed to look inside to see how the sausages are made. :-)

Ok, now you've looked. And you've seen that Windows is not one of those platforms whose complex calling convention requires memory allocation in a va_list. It turns out that you don't really need to use va_copy instead of simple assignment and that va_end actually does nothing. That was bad. You shouldn't have looked. Now you have to forget all that.

Because tomorrow everything might change. A new library or an update to the compiler optimisation logic, or who knows what, and all of a sudden va_copy is required, va_end prevents memory leaks, and your guilty knowledge suddenly turns out to be a dangerous error.

The standard says that you must use va_copy to copy a va_list. The standard says that you must call va_end for every initialised va_list. And you must do that. Because you can't know that it's not needed on your platform without snooping where you had no business going.

The standard library does not have to obey those rules. It can make complete knowledge of its platform and its own internals, since it only needs to work in its own environment. If something changes, the good folks who maintain the standard library will be aware of it, and they will make sure that the new version works with the new version of their compiler on their platform

So that's the deal: the implementation will guarantee that if you play by the rules, things will work. The rules are there so that implementors can deal with the peculiarities of their platform, and so that compilers can squeeze out as many optimised cycles as possible.

Sometimes it seems like cutting corners and breaking the rules won't hurt, at least not right here and right now. But don't yield to that temptation. Because if you do, you've left a time bomb in your code which will go off sooner or later.

Answer 2

If the compiler you're using is compliant with ISO C++ then va_copy is safe to use (this is a tautology).

It's conceivable that the FormatMessage function trashes the list, but I would assume it doesn't. If it did then the other suggestion in the linked article of restarting the list wouldn't work either.

Have you tried out the suggested code? The proper usage of va_copy would be:

va_list ap2;
va_copy(ap2, ap);

DWORD cchResult = FormatMessage(
           FORMAT_MESSAGE_FROM_HMODULE,
           g_hinst, dwMessageId, g_preferredLangId,
           pszBuffer, cchBuffer, &ap);

if (cchResult == 0) 
    cchResult = FormatMessage(
           FORMAT_MESSAGE_FROM_HMODULE,
           g_hinst, dwMessageId, g_fallbackLangId,
           pszBuffer, cchBuffer, &ap2);

va_end(ap2);