Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++ float-to-int conversion can be undefined behavior

kttnr.net

Post reply on HN
Print view View original

41–50 of 70 posts

Re: C++ float-to-int conversion can be undefined behavior

#41

Post by afdbcreid »

Maxatar wrote: post #10
digitalPhonix wrote: post #5

Herb Sutter's comment on why it's ok is confusing to me: > 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) 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 (o…

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

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

Re: C++ float-to-int conversion can be undefined behavior

#43

Post by wat10000 »

Maxatar wrote: post #24
cataphract wrote: post #16

Earlier quoted context omitted.

Undefined behavior is not the same as implementation-defined or unspecified behavior. A program with undefined behavior is by definition an incorrect program. But there are cases where the spec actually gives some margin to the implementation. Programs relying on the choices of the implementation may be correct, even if non-portable.

>A program with undefined behavior is by definition an incorrect program. This is simply false and an oft repeated myth. Undefined behavior has a specific technical definition that is in the C++ standard [1] and there is absolutely no mention in that definition or the implication of that definition that undefined behavior necessarily results in an invalid or incorrect program. The definition of undefined behavior, ri…

If the C++ standard imposes no requirements on such a program, then that means that the program is not C++. It's quite reasonable to describe such a program as an "incorrect [C++] program."

Re: C++ float-to-int conversion can be undefined behavior

#44

Post by deepsun »

Today people think that Java's main feature was OOP, but its main selling point was "no undefined behavior" (e.g. "int" means 32-bit signed integer with overflows, on any platform, no exceptions). Today it sounds normal, but back in the day that was what made Java popular.

Re: C++ float-to-int conversion can be undefined behavior

#45

Post by ranger_danger »

Maxatar wrote: post #23
achierius wrote: post #21

Earlier quoted context omitted.

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 g…

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.

I think they're saying that since they denote specific compiler versions as "officially supported", they can get away with saying the "UB" is not an issue in those versions only because they've already tested its behavior there, and anything else you compile with is untested and unsupported 'here be dragons' land.

You may wish they target every possible compiler brand and version, but they are free to disagree with you and only "support" specific ones.

Unfortunately this also has the same effect as the Linux kernel now in that it is no longer technically compliant with any C++ (or C) standard.

Re: C++ float-to-int conversion can be undefined behavior

#46

Post by Maxatar »

ranger_danger wrote: post #45
Maxatar wrote: post #23

Earlier quoted context omitted.

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.

I think they're saying that since they denote specific compiler versions as "officially supported", they can get away with saying the "UB" is not an issue in those versions only because they've already tested its behavior there, and anything else you compile with is untested and unsupported 'here be dragons' land. You may wish they target every possible compiler brand and version, but they are free to disagree with y…

How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library?

Your interpretation contradicts the statement that "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."

Re: C++ float-to-int conversion can be undefined behavior

#47

Post by ranger_danger »

Maxatar wrote: post #46
ranger_danger wrote: post #45

Earlier quoted context omitted.

I think they're saying that since they denote specific compiler versions as "officially supported", they can get away with saying the "UB" is not an issue in those versions only because they've already tested its behavior there, and anything else you compile with is untested and unsupported 'here be dragons' land. You may wish they target every possible compiler brand and version, but they are free to disagree with y…

How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library? Your interpretation contradicts the statement that "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 change…

> How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library?

Not special treatment for the library, but the library being able to assume that specific UB handling in certain existing compiler versions exists, can be relied on, and is compatible with the library's assumptions of such behavior, as long as those are the only versions they officially "support."

Re: C++ float-to-int conversion can be undefined behavior

#48

Post by Maxatar »

ranger_danger wrote: post #47
Maxatar wrote: post #46

Earlier quoted context omitted.

How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library? Your interpretation contradicts the statement that "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 change…

> How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library? Not special treatment for the library, but the library being able to assume that specific UB handling in certain existing compiler versions exists, can be relied on, and is compatible with the libra…

Here is the original statement about special treatment:

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

My claim is that Microsoft is not giving any special treatment to the GSL... the GSL is written using functionality that is officially available to any third party library, and hence not special.

Are you disputing this? If so then what is the special treatment you're claiming that Microsoft is giving to GSL or what special treatment is GSL making use of?

Re: C++ float-to-int conversion can be undefined behavior

#49

Post by ranger_danger »

Maxatar wrote: post #48
ranger_danger wrote: post #47

Earlier quoted context omitted.

> How does a library writer testing that their library works with a specific version of a compiler that was already released have anything to do with a compiler implementation providing special treatment for that library? Not special treatment for the library, but the library being able to assume that specific UB handling in certain existing compiler versions exists, can be relied on, and is compatible with the libra…

Here is the original statement about special treatment: "It was originally created by Microsoft and as Herb mentions "all our target platforms", so most likely it gets special treatment." My claim is that Microsoft is not giving any special treatment to the GSL... the GSL is written using functionality that is officially available to any third party library, and hence not special. Are you disputing this? If so then w…

I am not claiming there is any special treatment at all. I think the situation is much simpler:

They (Microsoft) test GSL with specific compiler versions to observe how their usage of the UB is treated, and if satisfactory, that compiler version is now "supported" in their eyes. They do not claim to "support" any other version because they have not tested them to know how the UB functions there.

Re: C++ float-to-int conversion can be undefined behavior

#50

Post by rhinocnc »

pjmlp wrote: post #35
20k wrote: post #28

Earlier quoted context omitted.

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 (some_double); so nothing fancy is going on here

Actually Microsoft has their own fork that ships with Visual Studio installer. However that was me guessing from Herb Sutter's reply.

yes, that is right
Post reply on HN