Title
Unnecessary constraints of va_start() usage
Status
c++14
Section
[support.runtime]
Submitter
Daniel Krügler

Created on 2011-11-12.00:00:00 last changed 131 months ago

Messages

Date: 2012-11-03.04:16:46

Proposed resolution:

This wording is relative to the FDIS.

Change [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 withof a function, array, or reference type, or withof 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.

Date: 2012-11-03.04:16:46

[ 2012, Portland: applied to WP ]

Date: 2012-02-27.16:24:02

[ 2012, Kona ]

Move to Ready.

Date: 2011-11-12.00:00:00

In [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()?

History
Date User Action Args
2014-02-20 13:20:35adminsetstatus: wp -> c++14
2012-11-03 04:16:46adminsetmessages: + msg6269
2012-10-25 12:46:45adminsetstatus: voting -> wp
2012-10-16 15:35:12adminsetstatus: ready -> voting
2012-02-27 16:24:02adminsetmessages: + msg6024
2012-02-12 18:36:43adminsetstatus: new -> ready
2011-11-28 22:10:52adminsetmessages: + msg5929
2011-11-12 00:00:00admincreate