5 ms·

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

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 3y ago
At the very minimum, you can simply do is_constant_evaluated to change behavior depending on runtime vs compile-time...
the_mitsuhiko 3y 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 3y 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 3y ago
    (nevermind)
    - jvanderbot 3y 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 3y ago
        [deleted]
    - jcelerier 3y ago
      Successful compilation of UB is explicitly disallowed by the standard in a constexpr context
      - layer8 3y 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 3y 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 3y ago
    Unless you used std::is_constant_evaluated() and the code running at runtime was not the one tested at compile time
  - ithkuil 3y 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 3y 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 3y 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 3y ago
  Constexpr at compile times gives that guarantee, not constexpr in general. Hence static assert to force comptime evaluation
  - soulbadguy 3y 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

AshamedCaptain 3y ago

At the very minimum, you can simply do is_constant_evaluated to change behavior depending on runtime vs compile-time...

the_mitsuhiko 3y 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 3y 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 3y ago
  (nevermind)
  - jvanderbot 3y 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 3y ago
      [deleted]
  - jcelerier 3y ago
    Successful compilation of UB is explicitly disallowed by the standard in a constexpr context
    - layer8 3y 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 3y 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 3y ago
  Unless you used std::is_constant_evaluated() and the code running at runtime was not the one tested at compile time
- ithkuil 3y 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 3y 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 3y 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 3y ago
Constexpr at compile times gives that guarantee, not constexpr in general. Hence static assert to force comptime evaluation
- soulbadguy 3y 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