This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.

### 2099. Unnecessary constraints of `va_start()` usage

Section: 17.13 [support.runtime] Status: C++14 Submitter: Daniel Krügler Opened: 2011-11-12 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [support.runtime].

View all issues with C++14 status.

Discussion:

In 17.13 [support.runtime] p3 we find (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 ...).227 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.

It seems astonishing that the constraints on function types and array types imposes these on the declared parameter `parmN`, not to the adjusted one (which would not require this extra wording, because that is implicit). This seems to say that a function definition of the form (Thanks to Johannes Schaub for this example)

>     #include <stdarg.h>

>     void f(char const paramN[], ...) {
>       va_list ap;
>       va_start(ap, paramN);
>       va_end(ap);
>     }

would produce undefined behaviour when used.

Similar wording exists in C99 and in the most recent C11 draft in 7.16.1.4 p4

In my opinion the constraints in regard to array types and function types are unnecessary and should be relaxed. Are there really implementations out in the wild that would (according to my understanding incorrectly) provide the declared and not the adjusted type of `paramN` as deduced type to `va_start()`?

[2012, Kona]

Move to Ready.

[2012, Portland: applied to WP]

Proposed resolution:

This wording is relative to the FDIS.

Change 17.13 [support.runtime] p3 as indicated:

> 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 ...).227 If the parameter `parmN` is declared with of a function, array, or reference type, or with of 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.