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

3011. Requirements for assert(E) inconsistent with C

Section: 19.3 [assertions] Status: Open Submitter: Jonathan Wakely Opened: 2017-08-18 Last modified: 2018-08-20

Priority: 2

View other active issues in [assertions].

View all other issues in [assertions].

View all issues with Open status.

Discussion:

The C standard says that the expression in an assert must have a scalar type, and implies (or at least allows) that the condition is tested by comparison to zero. C++ says that the expression is a constant subexpression if it can be contextually converted to bool. Those ways to test the condition are not equivalent.

It's possible to have expressions that meet the C++ requirements for a constant subexpression, but fail to meet the C requirements, and so don't compile.

#include <stdlib.h>

// A toy implementation of assert:
#define assert(E) (void)(((E) != 0) || (abort(), 0))

struct X {
  constexpr explicit operator bool() const { return true; }
};

constexpr bool f(const X& x) {
  assert(x);
  return true;
}

C++ says that assert(x) is a constant subexpression, but as it doesn't have scalar type it's not even a valid expression.

I think either 19.3.2 [cassert.syn] or 19.3.3 [assertions.assert] should repeat the requirement from C that E has scalar type, either normatively or in a note. We should also consider whether "contextually converted to bool" is the right condition, or if we should use comparison to zero instead.

[2017-11 Albuquerque Wednesday night issues processing]

Priority set to 2; status to Open

Jonathan is discussing this with WG14

[2018-08-20, Jonathan comments]

This was reported to WG14 as N2207.

Proposed resolution: