This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
va_argSection: 17.14.2 [cstdarg.syn] Status: New Submitter: Hubert Tong Opened: 2025-12-15 Last modified: 2026-01-17
Priority: Not Prioritized
View other active issues in [cstdarg.syn].
View all other issues in [cstdarg.syn].
View all issues with New status.
Discussion:
The wording in subclause 7.16.1.1 of both C17 and C23 has
"[if] type is not compatible with the type of the actual next argument (as promoted according to the default argument promotions) [...]".
17.14.2 [cstdarg.syn] only clarifies that the default argument promotions are replaced with the C++ version, seemingly leaving the C definition of "compatible" as operative for C++ in this context.
Consider, for example, the topic of CWG 3046, "Enumerations as part of the common initial sequence": Enumerations with the same underlying type need not have equivalent sets of values in C++, whereas C enumerations with the same underlying type are compatible and capable of representing the same values. Thus, enumerations should only be defined by C++ as being layout-compatible if, in addition to having the same underlying type, they also have equivalent sets of values. This difference between C++'s "layout-compatible" types and C's "compatible" types means that we should avoid using C's "compatible" in C++ contexts. Furthermore, C23 expanded the bullets. It now reads:[…] except for the following cases:
both types are pointers to qualified or unqualified versions of compatible types;
one type is compatible with a signed integer type, the other type is compatible with the corresponding unsigned integer type, and the value is representable in both types;
one type is pointer to qualified or unqualified void and the other is a pointer to a qualified or unqualified character type;
or, the type of the next argument is nullptr_t and type is a pointer type that has the same representation and alignment requirements as a pointer to a character type.
Assuming that "compatible" is read as "layout-compatible", the first bullet, whose effect in C is to allow limited differences in qualification, allows further differences in the pointee types in C++ because pointers are not layout-compatible in C++ when the pointee types are layout-compatible but not the same type.
Clearer wording, likely with more restrictions than C, is needed. A question, though, is whether "compatible" should generally be replaced (forva_arg) with "layout-compatible" or a requirement
for being the same type. In the specific case of the first bullet, I believe the latter is the right choice.
Proposed resolution: