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

21–30 of 70 posts

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

#21

Post by achierius »

Maxatar wrote: post #20
pjmlp wrote: post #17

Earlier quoted context omitted.

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

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.

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.

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

#22

Post by aw1621107 »

pjmlp wrote: post #18
digitalPhonix wrote: post #12

Earlier quoted context omitted.

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

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

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

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

#23

Post by Maxatar »

achierius wrote: post #21
Maxatar wrote: post #20

Earlier quoted context omitted.

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.

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.

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

#24

Post by Maxatar »

cataphract wrote: post #16
orangepanda wrote: post #8

How could it be defined behaviour, when the result is different on ARM and x86?

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, right from the standard itself is... and I quote... get ready for it...

"behavior for which this document imposes no requirements"

That's it, nothing more, nothing less.

The standard even goes out of its way to state the following:

"Permissible undefined behavior ranges from ignoring the situation completely with unpredictable results, *to behaving during translation or program execution in a documented manner* characteristic of the environment".

Behaving in a documented manner characteristic of an environment is a far cry from being by incorrect by definition.

[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/n49...

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

#26

Post by em3rgent0rdr »

LoganDark wrote: post #15
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…

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

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

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

#27

Post by 20k »

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…

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

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

#28

Post by 20k »

pjmlp wrote: post #7
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…

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.

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

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

#29

Post by cataphract »

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…

I appreciate the correction. Although it should be said that modern implementations tend to opt to assume that UB never happens.

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

#30

Post by 20k »

gpvos wrote: post #25

Sounds like the standard should say that it results in an implementation-defined value (or wording to that effect). Saying it's UB gives the compilers way too much leeway.

Its incredibly hard to get changes like this into the standard, because there's a core contingent of people who seem to feel that UB is part of C++'s identity, and then there's very vague hand waving about performance. There is luckily a pretty successful push in wg21 to start removing a lot of the more unnecessary UB, so hopefully this gets sent to the sausage factory as well
Post reply on HN