[expr.const] Macro invocations during constant evaluation

[Endilll]

Reference (section label): [expr.const]

Issue description:

[expr.const] paragraphs 10:

An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine ([intro.execution]), would evaluate one of the following:
— <...>
— an invocation of the va_arg macro ([cstdarg.syn]);

[expr.const] paragraph 12:

It is unspecified whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E would evaluate
— <...>
— an invocation of the va_start macro ([cstdarg.syn])

Macros do not exist by the time analysis regarding core constant expressions happens.

Suggested resolution:

Change [expr.const] bullet 10.30 as follows:

An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine ([intro.execution]), would evaluate one of the following:
— <...>
— an invocation of constructs resulting from the analysis of tokens expanded from the va_arg macro ([cstdarg.syn]);

Change [expr.const] bullet 12.2 as follows:

It is unspecified whether E is a core constant expression if E satisfies the constraints of a core constant expression, but evaluation of E would evaluate
— <...>
— an invocation of constructs resulting from the analysis of tokens expanded from the va_start macro ([cstdarg.syn]).

[Endilll]

Potentially relevant context: recent thread on SG22 reflector about va_start macro.

[jensmaurer]

These words for va_start and va_arg were intentionally chosen by CWG at the time, as "good enough".

[t3nsor]

I think the intent is to treat va_start and va_arg as if they were functions (which is how the C standard specifies them while also simultaneously stating that they are in fact macros).

That being the case, the proposed change in wording may actually be wrong. From C++26, invoking va_start(E) can still be a constant expression if the evaluation of E throws before va_start can be "entered" (and that exception is caught within the constant evaluation). Saying "constructs resulting from ... expanded ..." would imply that it's not a constant expression if you start evaluating the argument.

[Endilll]

I think the intent is to treat va_start and va_arg as if they were functions (which is how the C standard specifies them while also simultaneously stating that they are in fact macros).

If you're referring to Annex B of the C standard specifying them as functions, my understanding is that it's a defect that will be addressed editorially, because Annex B is informative.

Saying "constructs resulting from ... expanded ..." would imply that it's not a constant expression if you start evaluating the argument.

I don't disagree, but there is an adjacent issue. If in va_start(E, E2) E2 is the one throwing an exception, what the behavior should be? https://eel.is/c++draft/cstdarg.syn#1.2 says that preprocessing tokens of second (and subsequent) arguments are discarded. That said, this rule is problematic, because it makes it harder to issue a diagnostic that passing the second argument to va_start is deprecated.

[frederick-vs-ja]

See also CWG2299. Personally, I think it would be cleaner to specify such non-constant-ness in library wording.