Proposed resolution (February, 2017):

Change 17.13.2 [cstdarg.syn] paragraph 1 as follows:

The contents of the header <cstdarg> are the same as the C standard library header <stdarg.h>, with the following changes: 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 a pack expansion (13.7.4 [temp.variadic]) or an entity resulting from a lambda capture (7.5.6 [expr.prim.lambda]), the program is ill-formed, no diagnostic required. If the parameter parmN is of a reference type, or 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.

Notes from the December, 2016 teleconference:

Such examples should have undefined behavior; va_start should only be permitted to access the arguments for the current function.

[Adopted at the February/March, 2017 meeting.]

Consider:

  #include <cstdarg>
  #include <iostream>

  auto f(int i, ...) {
   return [&]() {
    va_list l;
    va_start(l, i);
    std::cout << "i = " << i << ", " << va_arg(l, int) << std::endl;
    va_end(l);
   };
  }

  int main() {
   auto l = f(100, 42);
   l();
  }

Is this defined behavior, accessing the variadic arguments passed to f?