Crate-training Tiamat, un-calling Cthulhu: Taming the UB monsters in C++
8 points by jmillikin
8 points by jmillikin
I admire Sutter’s work, and he’s written some great articles, but this one kind of smells like a puff-piece. Getting rid of UB is doing the Lord’s work, but it’s not the same as memory safety.
During constexpr evaluation, the language mandates well-defined behavior — no wild pointers, no uninitialized reads, no surprises. If an operation might trigger undefined behavior, the compiler simply rejects the constexpr evaluation at compile time.
So does this mean a function marked constexpr cannot cause UB because the compiler will always flag it as an error? Or does it only detect/reject UB during compile-time interpretation when the flow of control takes it to that point? If the latter, constexpr is considerably less useful as a safety mechanism because how much of that code actually runs at compile time?
I’m not super familiar with cosntexpr, but my underastanding is it’s only done when it executes at compile time and you don’t get runtime guarantees by slapping constexpr on a function, for example https://godbolt.org/z/GhhMGWfzP
I think it works as a safety mechanism because all the inputs to a constexpr, no matter how complex, have to be constant. Thus, whatever end result gets into the compiled code, it is completely well-defined and can’t change to UB at runtime, and in some sense the answer to your question doesn’t matter — either it doesn’t compile, or it happens to compile but it’s safe at runtime. This also explains why you can have nearly the whole language at compile time be UB-free, yet still not have a UB-free compiler mode, because the inputs at runtime are of course not constant.
It doesn’t work as a safety mechanism at all, because constexpr code also supports running on non-constant values at runtime, and furthermore nothing prevents a constexpr function from dynamically doing non-constexpr things when run this way. (This is an expected and well-supported way to write constexpr functions, even!)
The fact that C++ people trot this out every time UB comes up is a giant misdirection and borderline lying.
The compiler does complain if a constexpr function always does something not allowed. So I’m wondering how much UB can be caught this way, even when the function isn’t actually run at compile time.
It is a dynamic (i.e. during constexpr evaluation time) check, your “latter” version. For example: https://gcc.godbolt.org/z/3WY4a4M1c
Tech pundits still seem to commonly assume that UB is so fundamentally entangled in C++’s specification and programs that C++ will never be able to address enough UB to really matter.
I don’t think that’s really what people were saying. Instead they were saying that the C++ compiler and standard authors were not interested in eliminating UB culturally. This indicates that the culture is changing which is good but pretending like people thought it was technically infeasible as opposed to a cultural problem is disingenuous.
and most common non-iterator bounds errors in the hardened standard library, such as for string and vector and string_view and span, will no longer be UB in a “hardened” implementation.
Yay! This looks quite reasonable! I am a bit unsure about the fact that they don’t introduce an equivalent of unsafe/ @setRuntimeSafety(false); for granular opt out. I guess you get that by using .data() to fetch the raw pointer, but then it becomes ambiguous whether raw pointer usage is an intentional opt out, or just very old code.
Hardened standard library is built on top of the contracts system, which gives you a global tuning flag, but not individual ones.