Herb Sutter's comment on why it's ok is confusing to me:<p>> Regarding the use of UB internally: It's okay and if anyone is worried about it the use of UB is benign on the platforms we target (e.g., they don't involve hitting any hardware trap representations for these types)<p>Isn't the outcome of the UB (ie. whether it will "rm -rf /" or something else) dependent on both the target and the compiler? And the compiler (or future compiler) could plausibly make the assumption that the narrowing to an unrepresentable value will never occur and change behaviour because of it?
For what it's worth, a GSL developer later reopened that GitHub issue and stated that they're going to look into fixing the UB. Sutter may have just been stating an assumption.<p><a href="https://github.com/microsoft/GSL/issues/786#issuecomment-5133269178" rel="nofollow">https://github.com/microsoft/GSL/issues/786#issuecomment-513...</a><p>> I'll raise this issue in the next internal GSL sync. I'd agree with y'all that this behavior: <a href="https://godbolt.org/z/4Tr1fe9xG" rel="nofollow">https://godbolt.org/z/4Tr1fe9xG</a> is undesirable
In LLVM, the result of floating-to-int conversion that is out of range of the int is a poison value, which means you get essentially the full unpredictability of UB.<p>That said, I'm a little hard-pressed to think of optimizations that would actually take advantage of poison, because floating-point range isn't really computed in the optimizer.
Yeah Herb's 100% wrong here. Its common when people are downplaying the memory safety issues with C++ that they say things like this, but its completely incorrect. All invoked UB is potentially equally serious, and this is exploitable memory unsafety. Compilers can and do optimise away this kind of stuff (as other people have explained here)<p>There's also important context in that Herb is currently one of the people leading the current memory safety approach for C++
Yes, this is all true but Sutter's comment is that the specific platforms that this specific implementation of the GSL targets results in the correct output. The platforms officially supported are:<p>GCC 12, 13, 14<p>XCode 14.3.1, 15.4<p>Clang 16, 17, 18<p>Visual Studio with MSVC VS2019, VS2022<p>Visual Studio with LLVM VS2019, VS2022
No, UB is allowed special powers for compiler and standard library implementors, which is what Herb Sutter means with internal behaviour.<p>Meaning MSVC is aware of these cases, so the compiler has special cases for it.
Clang is a target for the GSL though. How can MSVC's special powers prevent this from being exploitable UB in Clang/LLVM?<p>This code boils down to static_cast<int>(some_double); so nothing fancy is going on here
GSL is not the standard library nor an internal runtime library. Its GitHub page claims that it supports a variety of compilers:<p>> The GSL officially supports recent major versions of Visual Studio with both MSVC and LLVM, GCC, Clang, and XCode with Apple-Clang
That's my point - GSL is <i>NOT</i> MSVC only, it's a general purpose library and <i>NOT</i> a standard library implementation of a toolchain so any compiler is expected to be able to compile it (it also explicitly targets clang & gcc).
UB is bad not because it actually leads to any particular result on any particular platform or compiler, but because semantically it invalidates assumptions about a program. Rust is explicit on this, but it absolutely still applies to C/C++.