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.

### 2413. `assert` macro is overconstrained

Section: 19.3 [assertions] Status: New Submitter: David Krauss Opened: 2014-06-25 Last modified: 2014-11-03

Priority: 4

View other active issues in [assertions].

View all other issues in [assertions].

View all issues with New 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.

Proposed resolution: