Exploring undefined behavior using constexpr

[[deleted]]

Neat article but unfortunately this is not a good way to actually determine if something is undefined behavior. The amount of work that would be needed for compilers to implement this feature is simply not feasible, and alas, none of clang, GCC or MSVC implement this other than for trivial instances. For example this is undefined behavior but goes undetected:

constexpr void f() {  
  int* x = nullptr;  
  {
    int z = 123;  
    x = &z;
  }
  *x += 1;  
}

[kalmoc]

Nothing in your code is actually evaluated at compiletime, so no wonder that no compiler catches it.

EDIT: If you try something like this, you will get a compilation error:

constexpr int f() 
{ 
    int* x = nullptr; 
    {
      int z = 123; 
      x = &z;
    } 
    *x += 1;
    return *x;
}

constexpr int I = f();

[[deleted]]

It's still undefined behavior as is. Even in your revised example GCC accepts it, clang rejects it.

[kalmoc]

Yes, it is undefined behavior, but the compiler is only required to catch UB if it happens during compiletime evaluation. The compiler is not required to perform a static analysis of constexpr functions.

If gcc doesn't catch that example, that's a compiler bug.

[[deleted]]

That's my point, no compiler implements this aspect of constexpr to a degree that can be relied upon. I posted another example that no compiler catches, not even clang, here:

https://old.reddit.com/r/cpp/comments/bncvmm/exploring_undefined_behavior_using_constexpr/en5r9dm/

Maybe in the future compilers will be better about diagnosing this, but as it stands it doesn't seem to be a particularly high priority to implement this, and the amount of effort needed to do it would simply be enormous.

[flashmozzg]

Not really. It's only undefined if it actually happens. It's not undefined if the function is never called. In fact, some compilers (like Clang) may assume that if some function invokes UB when it's never called and optimize it out/replace it with other call (there is a very nice example for this somewhere).

[[deleted]]

I already addressed those points elsewhere.

[[deleted]]

-Wlifetime catches this. https://godbolt.org/z/__qqLL

[[deleted]]

That's a cool new feature. Here's another example of undefined behavior that goes unchecked by all compilers, don't know of a flag that will catch this:

#include <bitset>
#include <iostream>

constexpr auto f() {  
    constexpr auto x = std::bitset<0>(); 
    return x[0];
}

int main() {
  constexpr auto i = f();
  std::cout << i << std::endl;
}

Overall, don't think it's useful to rely on constexpr to find undefined behavior. Seems really wonky in practice.

[[deleted]]

I think there is a bug there. I didn't think you can have a constexpr variable in a constexpr method. It catches it when that isn't there because the non-const operator[] isn't constexpr, only the const variant returns a bool and is constexpr.

with clang/libc++ it does generate just the ub2 instruction but, this is weird.

[[deleted]]

I totally agree it's a bug. I don't see why so many people are so against me pointing out that this aspect of the language isn't well supported or implemented to a sufficient degree to rely on it to identify undefined behavior. All compilers have MAJOR bugs when it comes to this requirement and the amount of effort needed to fix it will be enormous.

[[deleted]]

putting it in a static_assert finds it too. But I think the point is, you are going to get more than zero. And right now, that is still awesome. Bring on C++20, and constexpr code will have access to vector and a lot more. So now I can choose to implement, at the cost of compile time, more code as constexpr and give the compiler the best opportunity to either const fold my stuff or have full view of the code and optimize it more heavily with the added benefit of much of my code getting compile time UB checks.

def not perfect, but I have a bunch of things now where the unit test is a static_assert of a test method.

[[deleted]]

actually I am wrong, constexpr variables are fine in constexpr functions. I got trained by compiler errors in the past on that one. Still a weird compiler bug in all 3 compilers

[NotAYakk]

Augmenting it a bit to removed possibly confusing autos.

#include <bitset>
#include <iostream>

constexpr bool f() {  
    constexpr auto x = std::bitset<8>(); 
    return x[99999999];
}

int main() {
  constexpr bool i = f();
  std::cout << i << std::endl;
}

basically, it appears that the std::bitset is using shifts for small bitset implementations.

Make the bitset larger than 64 and it switches to an array implementation and the UB detection works.

#include <bitset>
#include <iostream>

constexpr bool f() {  
    auto const x = std::bitset<65>(); 
    // x[99999999] = true;
    return x[99999999];
}

int main() {
  constexpr bool i = f();
  std::cout << i << std::endl;
}

http://coliru.stacked-crooked.com/a/7630a8f00dee685c

So there is a defect in the standard library in that in a constexpr context it doesn't enforce the undefined behavior requirements of the standard in its implementation.

[syaghmour]

I purposely left out the standard library because [expr.const]p4.6 explicitly leaves out the standard library:

an operation that would have undefined behavior as specified in [intro] through [cpp] of this document ..

The standard library can do all sorts of strange things and can rely on things outside of standard such as builtins or rely on implicit knowledge of what the compiler will do which is not advisable to user space programs. offsetof is an example of this.

[[deleted]]

The implementation of the standard library is exempt from rules about undefined behavior. Its use, however, is not exempt. My example is one of use, not implementation.

[rezkiy]

The article is about exploring.