[dgellow]

https://en.cppreference.com/w/cpp/language/constant_expressi...

Point 8:

> A core constant expression is any expression whose evaluation would not evaluate any one of the following:

> 8. an expression whose evaluation leads to any form of core language undefined behavior (including signed integer overflow, division by zero, pointer arithmetic outside array bounds, etc).

[AshamedCaptain]

This does not really "guarantee" anything. You can still have as much UB (incl leaks) as you want, as long as they are not evaluated at compile-time. i.e. it's at best equivalent to running valgrind.

[dgellow]

What would be examples of runtime UBs that wouldn’t be reported when used within a constexpr?

[simiones]

The point is that the code is only checked for UB with the arguments it is given at compile time. There is no guarantee that it can't invoke UB with other arguments it might receive at runtime.

For example, here is a modification of the original program that does invoke UB, but compiles just fine:

https://godbolt.org/z/MaqhcEYqn

[dgellow]

Oh yes, I see your point. Thanks for clarifying

[tlb]

Indeed, it fails if you invoke UB. For example, an int overflow in a constexpr causes a compile error:

  <source>:5:17: error: static assertion expression is not an integral constant expression
    static_assert(1024*1024*1024*3 != 0, "UB");

https://godbolt.org/z/Wc591En7E

[simiones]

That only works if you know the values at compile-time though:

  constexpr int foo(int x) {
    return 1024*1024*1024*x;
  }
  
  int main()
  {
    int y;
    std::cin >> y;
    static_assert(foo(1));  //all good
    foo(y);                 //oops, UB if user enters 7
  }

https://godbolt.org/z/K8h4Kj99s

Edit: small correction so that the numbers are big enough to cause problems...

[mort96]

Yeah, the tests will only fail if the tests trigger UB. It's like all testing, it only detects issues if you trigger the issues in the tests. Using static_assert as your test system obviously doesn't obviate the need for writing good tests.

[tsimionescu]

Many people in this thread think that if a constexpr function can be called at compile time successfully, it will also be guaranteed not to have UB at runtime, in general.

I was pointing out that this is only true for the cases you actually test, not the general case.

Even then, it's not fully true, as a function may have different behavior at runtime as opposed to compile time (e.g. because of multi-threading), and so it may display UB even when called with the same arguments that didn't display UB at compile-time.

Overall, this static_assert trick is just a nice way to make sure your tests don't accidentally pass while still invoking UB, to protect from false negatives.

[mort96]

Aha, I think I see. Upon reflection, I do remember that some people seem to think that UB is a property of the code, not the execution; that a piece of code either "contains UB" or does not. I suppose it makes sense then that some people may think that code which works under constexpr can't "contain UB" and get the wrong idea.

[mgaunard]

Try forcing the call to happen at compile-time.

constexpr requires that the function be callable at compile-time, not that it is so.

[tsimionescu]

You can't call an expression whose value is IO-dependent in a compile-time context, obviously.

The tweet seems to imply that if you can call your functions at compile time, they will not present UB at runtime either. I am trying to point out that that is not the case at all.

[mgaunard]

That seems unrelated to the sub-thread in question.

[tsimionescu]

The example program is calling foo(y), where the value of y is read from standard input. You suggested to evaluate that expression at compile time, which is not possible. How is this unrelated to the thread?

[layer8]

I hope there’s also some text in the standard prohibiting implementations from allowing any other expressions as a constant expression (which they otherwise could as a language extension), and thus requires compilation failure for such expressions?

[kps]

Pragmatically, you can't stop extensions; if the fine print for `--std=cool++23` says that this mode is not actually C++23-compliant, nearly nobody will ever notice or care. Pragmatically, if a popular compiler makes `--std=cool++23` the default, and requires `--std=C++23 --iso-eic-jtc1-sc22-wg21 --pompous` to get standard-conforming behaviour, nearly nobody will do that; instead they will complain that other compilers lack the extensions.

[layer8]

Extensions can be standard-compliant, in the sense that they don’t violate any prescription by the standard, and thus a program cannot assume their absence. My question was whether the standard actually takes care to render the acceptance of constexprs-with-UB non-standard-compliant. That is, in addition to “must accept X”, does it also say “must only accept X”?