C allows cv qualifiers to differ,

I don't believe this is the case. 6.2.7 says two types are compatible if they're the same, otherwise see elsewhere. 6.7.3 is the elsewhere for type qualifiers and says (in p10): "For two qualified types to be compatible, both shall have the identically qualified version of a compatible type; the order of type qualifiers within a list of specifiers or qualifiers does not affect the specified type."

and IIRC also allows signed/unsigned mismatches.

I also don't think this is correct. 6.2.7 leads us to 6.7.2 for type specifiers where it shows signed/unsigned are not the same type.

I checked with David Keaton from WG14 and he agreed with my analysis of the C standard. Do you think this is still too large to fix editorially?

@tkoeppe Thanks, you're right -- I was thinking of this rule (from 7.16.1.1/2):

If there is no actual next argument, or if type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions), the behavior is undefined, except for the following cases:

• one type is a signed integer type, the other type is the corresponding unsigned integer type, and the value is representable in both types;
• one type is pointer to void and the other is a pointer to a character type.

... but we're talking about va_start not va_arg here so this is irrelevant.

Taking a step back, the current wording simply makes no sense. How can a parameter be "of a type that is the same as the type that results when passing an argument for which there is no parameter"? There is no meaningful notion of "the type that results when passing an argument for which there is no parameter" in isolation.

Perhaps this means "parmN shall be of a non-reference type such that applying the default argument promotions to a prvalue of the parameter's type would not change its type"? But... this constraint seems pointless. What are we trying to defend against here? Why should this not be required to work:

void x(float f, ...) { // or with nullptr_t instead of float
va_list l; va_start(l, f);
// ...
}

? And what about the multitude of cases where passing an argument of that type with no corresponding parameter would be ill-formed (by being conditionally-supported), such as:

void y(std::string s, ...) {
va_list l; va_start(l, s);
// ...
}

?

@zygoloid: Yes, all good points. Indeed, the meaning is that the type of paramN must default-promote to itself. Why the rule is there only God knows, but indeed it seems that C does not want to allow void f(float, ...).

I'm not actually sure if we ever say whether void y(std::string s, ...) is allowed. Or a reference parameter. I agree that there doesn't appear to be a reason for this constraint.

What are we trying to defend against here?

@zygoloid: my understanding from talking to David is that this restriction is in place for platforms that want to implement va_start in pure C. He quoted the rationale document:

"The parmN argument to va_start was intended to be an aid to implementors writing the definition of a conforming va_start macro entirely in C, even using pre-C89 compilers (for example, by taking the address of a parameter). The restrictions on the declaration of the parmN parameter follow from the intent to allow this kind of implementation, as applying the & operator to a parameter name might not produce the intended result if the parameter's declaration did not meet these restrictions."

(Quote pulled from http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf)

I opened a Core issue for this, whose resolution will subsume this proposed change. Closing for now, and thank you for bringing this up!