C++ float-to-int conversion can be undefined behavior
1–10 of 70 posts
Re: C++ float-to-int conversion can be undefined behavior
#2[dead]
Re: C++ float-to-int conversion can be undefined behavior
#3[deleted]
Re: C++ float-to-int conversion can be undefined behavior
#4The core guidelines library is definitely not doing the right thing here. Very odd.
Re: C++ float-to-int conversion can be undefined behavior
#5Herb 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 (or future compiler) could plausibly make the assumption that the narrowing to an unrepresentable value will never occur and change behaviour because of it?
Re: C++ float-to-int conversion can be undefined behavior
#6Hopefully this will be part of UB fixes for C++29, where plenty of UB is being redefined as erroneous behaviour instead.
Re: C++ float-to-int conversion can be undefined behavior
#7Herb 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.
Re: C++ float-to-int conversion can be undefined behavior
#8How could it be defined behaviour, when the result is different on ARM and x86?
Re: C++ float-to-int conversion can be undefined behavior
#9How could it be defined behaviour, when the result is different on ARM and x86?
Architecture dependent is not the same as undefined.
Re: C++ float-to-int conversion can be undefined behavior
#10Herb 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