undefined

points

[-]

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.

https://github.com/microsoft/GSL/issues/786#issuecomment-513...

> I'll raise this issue in the next internal GSL sync. I'd agree with y'all that this behavior: https://godbolt.org/z/4Tr1fe9xG is undesirable

by mort962 hours ago|

parent|

[-]

But ... surely Sutter ought to know better than to say "because the hardware handles this conversion reasonably, it's a benign case of UB"? Surely he knows that compilers can and will optimize based on the assumption that UB never happens?

The problem isn't, "oh no what if my CPU's float->int conversion instruction traps", that's an extremely naive way to think about UB. Everyone who has thought seriously about UB in C++ for any length of time knows this. It's worrying that this was Sutter's response.

by 20k3 hours ago|

prev|

[-]

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)

There's also important context in that Herb is currently one of the people leading the current memory safety approach for C++

by jcranmer4 hours ago|

prev|

[-]

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.

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.

by mort961 hours ago|

parent|

[-]

Here's (my modified version of) an example someone came up with on lobste.rs: https://godbolt.org/z/e69b4Tqbs

I don't know exactly which optimization passes do what, but a few observations:

* The 'foo(unsigned int n)' function should never return a value that's greater than 'n', since it returns 'i < n ? i : n'.

* The value printed by the 'foo' function should always be the same as the value that's returned.

Yet the value it prints is 2700624104 (which is greater than 'n', which is 10 in this case), and the returned value is 2700623376, which is different. (The exact numbers vary run to run)

If the conversion "just" resulted in a bogus value, we would have expected some number <=10 to be printed two times.

by Maxatar5 hours ago|

prev|

[-]

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:

GCC 12, 13, 14

XCode 14.3.1, 15.4

Clang 16, 17, 18

Visual Studio with MSVC VS2019, VS2022

Visual Studio with LLVM VS2019, VS2022

by afdbcreid1 hours ago|

parent|

[-]

Then this is, unfortunately, entirely wrong. Here's an example causing a segfault when there is a bound checks that the compiler omits:

https://godbolt.org/z/8f6rv4dja

The example is adapted from a Rust example shown by @RalfJung in https://lobste.rs/s/ba2yfy/c_float_int_conversion_can_be_und....

by pjmlp5 hours ago|

prev|

[-]

No, UB is allowed special powers for compiler and standard library implementors, which is what Herb Sutter means with internal behaviour.

Meaning MSVC is aware of these cases, so the compiler has special cases for it.

by digitalPhonix5 hours ago|

parent|

[-]

That's my point - GSL is NOT MSVC only, it's a general purpose library and NOT a standard library implementation of a toolchain so any compiler is expected to be able to compile it (it also explicitly targets clang & gcc).

by pjmlp4 hours ago|

parent|

[-]

It was originally created by Microsoft and as Herb mentions "all our target platforms", so most likely it gets special treatment.

by aw16211074 hours ago|

parent|

[-]

At the time Herb made that comment GSL was documented as supporting XCode 12.5.1/13.2.1, GCC 10/11, Clang 11/12, and Visual Studio 2019/2022 using both MSVC/LLVM [0]. Even if MSVC had special support for GSL I'm a bit more skeptical that such support would extend to XCode, GCC, and Clang.

[0]: https://github.com/microsoft/GSL/tree/99a29ce797c8337b8923f2...

by wavemode5 hours ago|

parent|

prev|

[-]

GSL is not the standard library nor an internal runtime library. Its GitHub page claims that it supports a variety of compilers:

> The GSL officially supports recent major versions of Visual Studio with both MSVC and LLVM, GCC, Clang, and XCode with Apple-Clang

by pjmlp4 hours ago|

parent|

[-]

It was originally created by Microsoft and as Herb mentions "all our target platforms", so most likely it gets special treatment.

by Maxatar4 hours ago|

parent|

[-]

There is absolutely no special treatment afforded to the GSL by any of the target platforms. While we can't inspect MSVC's source code, both clang and GCC do not have any support or affordance for the GSL whatsoever and it would be very unusual to expect MSVC's source code to have some kind of affordance for this library.

by achierius4 hours ago|

parent|

[-]

The 'special treatment' isn't technical, it's procedural -- insofar as if, during development for a new release, MSVC were to land some changes that broke GSL, Microsoft's testing would catch that and ensure that the changes were reverted or fixed to support the latter, prior to shipping. Since they're built as part of the same operating system, they can make sure not to step on one another's toes -- which is not a guarantee that they can make to third-party applications.

by tsimionescu3 hours ago|

parent|

[-]

If you've ever read anything about the internal culture in Microsoft, you'd know this is extremely implausible.

by Maxatar4 hours ago|

parent|

prev|

[-]

I have no idea where you possibly got this idea from since the Github Issues tracker for GSL has numerous instances of new releases of MSVC breaking GSL compilation.

by 20k3 hours ago|

parent|

prev|

[-]

Clang is a target for the GSL though. How can MSVC's special powers prevent this from being exploitable UB in Clang/LLVM?

This code boils down to static_cast<int>(some_double); so nothing fancy is going on here

by pjmlp3 hours ago|

parent|

[-]

Actually Microsoft has their own fork that ships with Visual Studio installer.

However that was me guessing from Herb Sutter's reply.

by LoganDark5 hours ago|

prev|

[-]

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++.

by em3rgent0rdr3 hours ago|

parent|

[-]

Well because it could lead to any result on some platform or compiler, it invalidates assumptions about the program.

by LoganDark1 hours ago|

parent|

[-]

UB invalidates assumptions about the program not necessarily because it leads to arbitrary behavior in practice, but because it leads to arbitrary behavior in spirit. Even if there is no compiler in existence where the UB causes a problem, that does not make the program correct. UB is about whether the program is correctly defined, not about whether it works or not.