5 ms·

I really don't think it works that way. You can for sure write code that will leak and otherwise be UB but run compile-time just fine.

kris-jusiak 4y ago
constexpr has to checked for leaks and UB so as long as there is coverage at compile-time (static_assert + constexpr) I would assume there shouldn't be neither leaks nor UB. But the context is limitted where that can be applied and actually compiles. For example, there is no way to do it with global variables but with limited scope that's possible.
- AshamedCaptain 4y ago
  At the very minimum, you can simply do is_constant_evaluated to change behavior depending on runtime vs compile-time...
- the_mitsuhiko 4y ago
  I _think_ you cannot conclude from a constexpr not having UB at compile time that it won’t have UB at runtime.
  - kris-jusiak 4y ago
    I guess so, can't think of an example now but I'm pretty sure there are subtle corner cases (as always) and it depends on the testing, coverage and potential limitations of checking things at compile-time, though, IMHO, the technique is promissing and can help with a lot of use cases but defo not everything.
    - layer8 4y ago
      (nevermind)
      - jvanderbot 4y ago
        I think it's worth pointing out that your statement is true by definition, perhaps not true by implementation in these cases. It's not like UB produces _random_ behavior, it's just not specified what compilers _should_ do in those cases. Of course, cannot be relied upon.
        deleted 4y ago
        [deleted]
      - jcelerier 4y ago
        Successful compilation of UB is explicitly disallowed by the standard in a constexpr context
        layer8 4y ago
        Thanks, I wasn’t aware. Although that seems to be restricted to core language UB and not include standard-library UB: https://stackoverflow.com/a/72494688/623763 https://stackoverflow.com/a/72494688/623763
  - DannyBee 4y ago
    The standard explicitly disallows compiling of UB for constexpr. Otherwise, what you write is provably correct - UB is not statically decidable in all cases (and depending on the type of UB, not even in a lot of cases).
    - jenadine 4y ago
      Unless you used std::is_constant_evaluated() and the code running at runtime was not the one tested at compile time
    - ithkuil 4y ago
      Doesn't it depend on the actual values? If your compile time evaluations don't trigger signed integer overflow (or any other UB) does it follow that at runtime you couldn't pass a parameter that would trigger signed overflow? I mean it's still useful because at least you know your test code is not artificially passing because of some UB makes it look like passing
      - tialaramex 4y ago
        > it's still useful because at least you know your test code is not artificially passing because of some UB makes it look like passing Right, that's the extent of what this does. When I saw it on r/cpp I thought OK, somebody realised now they can make their C++ tests work as a reasonable person would expect, or perhaps realised that without this C++ tests are almost worthless because they can invoke Undefined Behaviour silently. But increasingly I suspect the OP mistook this for a breakthrough in correctness which it isn't, otherwise why post it to HN? On the other hand, the prohibition on UB for constexpr doesn't reach up to where IFNDR lives, so I'd guess most non-trivial C++ software is technically nonsense with no defined meaning as a result of IFNDR regardless of how many or few unit tests were written or whether they use constexpr to prohibit Undefined Behaviour. A cheerful thought. [Ill-Formed, No Diagnostic Required: A recurring statement in the C++ ISO document which basically says if you did this then too bad, that's not a well-formed C++ program, however your compiler may not notice that this isn't a C++ program, so, your program might compile, and even execute, but what if anything happens when you run it isn't specified in this ISO standard, good luck.]
- soulbadguy 4y ago
  >constexpr has to checked for leaks and UB so as long as there is coverage at compile-time Source ?I am not sure constexpr give any garanty regarding UB and/or leaks
  - 3836293648 4y ago
    Constexpr at compile times gives that guarantee, not constexpr in general. Hence static assert to force comptime evaluation
    - soulbadguy 4y ago
      > Constexpr at compile times gives that guarantee Can you point to a source for that ? I am not trying to be pendantic, but genuilly curious
dgellow 4y ago
https://en.cppreference.com/w/cpp/language/constant_expression 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).
- layer8 4y ago
  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 4y ago
    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 4y ago
      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”?
- tlb 4y ago
  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 https://godbolt.org/z/Wc591En7E

kris-jusiak 4y ago

constexpr has to checked for leaks and UB so as long as there is coverage at compile-time (static_assert + constexpr) I would assume there shouldn't be neither leaks nor UB. But the context is limitted where that can be applied and actually compiles. For example, there is no way to do it with global variables but with limited scope that's possible.

AshamedCaptain 4y ago
At the very minimum, you can simply do is_constant_evaluated to change behavior depending on runtime vs compile-time...
the_mitsuhiko 4y ago
I _think_ you cannot conclude from a constexpr not having UB at compile time that it won’t have UB at runtime.
- kris-jusiak 4y ago
  I guess so, can't think of an example now but I'm pretty sure there are subtle corner cases (as always) and it depends on the testing, coverage and potential limitations of checking things at compile-time, though, IMHO, the technique is promissing and can help with a lot of use cases but defo not everything.
  - layer8 4y ago
    (nevermind)
    - jvanderbot 4y ago
      I think it's worth pointing out that your statement is true by definition, perhaps not true by implementation in these cases. It's not like UB produces _random_ behavior, it's just not specified what compilers _should_ do in those cases. Of course, cannot be relied upon.
      - deleted 4y ago
        [deleted]
    - jcelerier 4y ago
      Successful compilation of UB is explicitly disallowed by the standard in a constexpr context
      - layer8 4y ago
        Thanks, I wasn’t aware. Although that seems to be restricted to core language UB and not include standard-library UB: https://stackoverflow.com/a/72494688/623763 https://stackoverflow.com/a/72494688/623763
- DannyBee 4y ago
  The standard explicitly disallows compiling of UB for constexpr. Otherwise, what you write is provably correct - UB is not statically decidable in all cases (and depending on the type of UB, not even in a lot of cases).
  - jenadine 4y ago
    Unless you used std::is_constant_evaluated() and the code running at runtime was not the one tested at compile time
  - ithkuil 4y ago
    Doesn't it depend on the actual values? If your compile time evaluations don't trigger signed integer overflow (or any other UB) does it follow that at runtime you couldn't pass a parameter that would trigger signed overflow? I mean it's still useful because at least you know your test code is not artificially passing because of some UB makes it look like passing
    - tialaramex 4y ago
      > it's still useful because at least you know your test code is not artificially passing because of some UB makes it look like passing Right, that's the extent of what this does. When I saw it on r/cpp I thought OK, somebody realised now they can make their C++ tests work as a reasonable person would expect, or perhaps realised that without this C++ tests are almost worthless because they can invoke Undefined Behaviour silently. But increasingly I suspect the OP mistook this for a breakthrough in correctness which it isn't, otherwise why post it to HN? On the other hand, the prohibition on UB for constexpr doesn't reach up to where IFNDR lives, so I'd guess most non-trivial C++ software is technically nonsense with no defined meaning as a result of IFNDR regardless of how many or few unit tests were written or whether they use constexpr to prohibit Undefined Behaviour. A cheerful thought. [Ill-Formed, No Diagnostic Required: A recurring statement in the C++ ISO document which basically says if you did this then too bad, that's not a well-formed C++ program, however your compiler may not notice that this isn't a C++ program, so, your program might compile, and even execute, but what if anything happens when you run it isn't specified in this ISO standard, good luck.]
soulbadguy 4y ago
>constexpr has to checked for leaks and UB so as long as there is coverage at compile-time Source ?I am not sure constexpr give any garanty regarding UB and/or leaks
- 3836293648 4y ago
  Constexpr at compile times gives that guarantee, not constexpr in general. Hence static assert to force comptime evaluation
  - soulbadguy 4y ago
    > Constexpr at compile times gives that guarantee Can you point to a source for that ? I am not trying to be pendantic, but genuilly curious

dgellow 4y ago

https://en.cppreference.com/w/cpp/language/constant_expression 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).

layer8 4y ago
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 4y ago
  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 4y ago
    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”?
tlb 4y ago
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 https://godbolt.org/z/Wc591En7E