4 ms·

std::unreachable() feels like it's what std::assert(false) should be, except that std::assert(false) is bizarrely defined (as a no-op) when NDEBUG is defined. T

by addaon 4y ago

std::unreachable() feels like it's what std::assert(false) should be, except that std::assert(false) is bizarrely defined (as a no-op) when NDEBUG is defined. This is one of those strange cases where the spec defines behavior that I'd strongly expect to be undefined.

int_19h 4y ago
What's bizarre about asserts being disabled if you explicitly ask for it?
- addaon 4y ago
  I'm not asking for the assert to be disabled. I'm asking for debugging features to be disabled. (NDEBUG == "no debug.") The debugging feature of an assert statement is that it performs work to check if the assertion is true and provides diagnostics if not. Disabling the debugging feature of an assert would, in my mind, make it purely an assertion -- an assumption that the compiler can count on (since this is true by design and demonstrated during debugging). Which is to say, it becomes undefined (contrary to compiler assumptions) if the condition is false. Another way of thinking of this: With NDEBUG undefined, the sequence `assert(condition); if(!condition) action();` is perfectly reasonable and equivalent to the naked assert. But, because assert(false) is defined, defining NDEBUG changes the semantics of the code, with the two examples having identical behavior when NDEBUG is unset, and different behavior when NDEBUG is set. This is contrary to my understanding of the intent of NDEBUG, to suppress debugging information without changing semantics. A third view: With NDEBUG undefined (which is normal for test and development), /I have no way of testing what happens past an assert(false)/. If I then define NDEBUG for a release build, I'm by definition exposing my user to untested code. The compiler might (with a defined assert(false)) define the behavior of this new code, /but I cannot, since I can't test it./ It just makes more sense to acknowledge that anything past an event horizon is undefinable, and call it undefined.
  - randomNumber7 4y ago
    The D Programming language actually uses assert(0) in that way. Except its not undefined behaviour if the code is reached in release builds. The compiler will put in a special assembly instruction which chrashes the programm.
  - int_19h 4y ago
    The sole intent of NDEBUG in the Standard is to suppress assert(). There's a reasonable argument to be made here that it's poorly named (although I suspect that ANSI simply standardized existing practice here, as they did with much of the standard).
    - 3836293648 4y ago
      Surely you mean ISO and not ANSI? Were such ugly hacks already a part of C89?
      - jwilk 4y ago
        > Were such ugly hacks already a part of C89? Yes.
      - int_19h 4y ago
        In fact, it turns out that it was already in K&R C ten years before C89: https://github.com/dspinellis/unix-history-repo/blob/Research-V7/usr/include/assert.h https://github.com/dspinellis/unix-history-repo/blob/Researc...

by addaon 4y ago

int_19h 4y ago

What's bizarre about asserts being disabled if you explicitly ask for it?

addaon 4y ago
I'm not asking for the assert to be disabled. I'm asking for debugging features to be disabled. (NDEBUG == "no debug.") The debugging feature of an assert statement is that it performs work to check if the assertion is true and provides diagnostics if not. Disabling the debugging feature of an assert would, in my mind, make it purely an assertion -- an assumption that the compiler can count on (since this is true by design and demonstrated during debugging). Which is to say, it becomes undefined (contrary to compiler assumptions) if the condition is false. Another way of thinking of this: With NDEBUG undefined, the sequence `assert(condition); if(!condition) action();` is perfectly reasonable and equivalent to the naked assert. But, because assert(false) is defined, defining NDEBUG changes the semantics of the code, with the two examples having identical behavior when NDEBUG is unset, and different behavior when NDEBUG is set. This is contrary to my understanding of the intent of NDEBUG, to suppress debugging information without changing semantics. A third view: With NDEBUG undefined (which is normal for test and development), /I have no way of testing what happens past an assert(false)/. If I then define NDEBUG for a release build, I'm by definition exposing my user to untested code. The compiler might (with a defined assert(false)) define the behavior of this new code, /but I cannot, since I can't test it./ It just makes more sense to acknowledge that anything past an event horizon is undefinable, and call it undefined.
- randomNumber7 4y ago
  The D Programming language actually uses assert(0) in that way. Except its not undefined behaviour if the code is reached in release builds. The compiler will put in a special assembly instruction which chrashes the programm.
- int_19h 4y ago
  The sole intent of NDEBUG in the Standard is to suppress assert(). There's a reasonable argument to be made here that it's poorly named (although I suspect that ANSI simply standardized existing practice here, as they did with much of the standard).
  - 3836293648 4y ago
    Surely you mean ISO and not ANSI? Were such ugly hacks already a part of C89?
    - jwilk 4y ago
      > Were such ugly hacks already a part of C89? Yes.
    - int_19h 4y ago
      In fact, it turns out that it was already in K&R C ten years before C89: https://github.com/dspinellis/unix-history-repo/blob/Research-V7/usr/include/assert.h https://github.com/dspinellis/unix-history-repo/blob/Researc...