This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

2413. assert macro is overconstrained

Section: 19.3 [assertions] Status: NAD Submitter: David Krauss Opened: 2014-06-25 Last modified: 2023-06-13

Priority: 4

View all other issues in [assertions].

View all issues with NAD status.

Discussion:

When NDEBUG is defined, assert must expand exactly to the token sequence ((void)0), with no whitespace (C99 §7.2/1 and also C11 §7.2/1). This is a lost opportunity to pass the condition along to the optimizer.

The user may observe the token sequence using the stringize operator or discriminate it by making a matching #define directive. There is little chance of practical code doing such things. It's reasonable to allow any expansion that is a void expression with no side effects or semantic requirements, for example, an extension keyword or an attribute-specifier finagled into the context.

Conforming optimizations would still be limited to treating the condition as hint, not a requirement. Nonconformance on this point is quite reasonable though, given user preferences. Anyway, it shouldn't depend on preprocessor quirks.

As for current practice, Darwin OS <assert.h> provides a GCC-style compiler hint __builtin_expect but only in debug mode. Shouldn't release mode preserve hints?

Daniel:

The corresponding resolution should take care not to conflict with the intention behind LWG 2234.

[2023-06-13, Varna; Status changed: New → NAD.]

Only observable by stringifying an assert expression anyway, so arguably allowed by implementations anyway. Needs a paper to make changes here, or incorporate into P2884.

Proposed resolution: