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

11–20 of 70 posts

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

#11

Post by wavemode »

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.

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

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

#12

Post by digitalPhonix »

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.

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

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

#13

Post by stouset »

marcosdumay wrote: post #9
orangepanda wrote: post #8

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

Architecture dependent is not the same as undefined.

Also, the spec says it’s undefined. But compiler authors can always special-case their own compilers.

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

#14

Post by wavemode »

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…

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

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

#15

Post by LoganDark »

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

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

#16

Post by cataphract »

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.

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

#17

Post by pjmlp »

wavemode wrote: post #11
pjmlp wrote: post #7

Earlier quoted context omitted.

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.

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

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

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

#18

Post by pjmlp »

digitalPhonix wrote: post #12
pjmlp wrote: post #7

Earlier quoted context omitted.

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.

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.

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

#19

Post by jcranmer »

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…

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.

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

#20

Post by Maxatar »

pjmlp wrote: post #17
wavemode wrote: post #11

Earlier quoted context omitted.

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

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.
Post reply on HN