In C/C++ just adding two integers can lead to undefined behaviour. Your expectations are too high.
C++ float-to-int conversion can be undefined behavior
51–60 of 70 posts
Re: C++ float-to-int conversion can be undefined behavior
#52Earlier quoted context omitted.
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
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…
I think this actually demonstrates why Rust's safety culture is what's crucial, not the safety technology they have built to enable that culture and which is relatively easier to duplicate.
The natural instinct of humans is to deny problems. Their safety culture very strongly encourages Rustaceans encountering the equivalent issue [this really happened, you could write this nasty conversion bug in Rust 1.0 no problem but for years now Rust panics] to accept that there is a safety problem - and from there they can begin actually addressing the problem rather than pretending it doesn't exist. It's not perfect, but the alternatives are definitely worse.
The technology doesn't do this. The Rust compiler would be entirely OK with Rust shipping a standard library where safe APIs like Vec::pop can induce Undefined Behaviour. That's not allowed culturally, but technically Vec::pop already has an unsafe block, it could cause UB if it wanted to.
Re: C++ float-to-int conversion can be undefined behavior
#53Earlier quoted context omitted.
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.
What is the relationship between your claim, and the claim I replied to about GSL having special treatment? In other words, why did you reply to me with an interpretation about a post that claimed GSL is afforded special treatment by MSVC if your claim is that GSL does not get any special treatment from MSVC?
Did you intend to reply to someone else?
Re: C++ float-to-int conversion can be undefined behavior
#54Earlier quoted context omitted.
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…
I think this actually demonstrates why Rust's safety culture is what's crucial, not the safety technology they have built to enable that culture and which is relatively easier to duplicate. The natural instinct of humans is to deny problems. Their safety culture very strongly encourages Rustaceans encountering the equivalent issue [this really happened, you could write this nasty conversion bug in Rust 1.0 no problem…
Nitpick: Rust doesn't panic in this situation, it saturates (i.e., returns the largest possible value for the given integer type). Among other reasons, because a lot of existing programs that triggered this UB happened to work in practice, and would have experienced the panicking behavior as a severe regression.
This case also shows the limits of Rust's safety culture; they knew about the problem for a long time, and could have fixed it right away if they'd been willing to make programs that do a lot of float-to-int casts eat a performance regression, but a number of users objected strongly to this. So it remained unfixed until they figured out a way to make it fast enough that no one would really notice.
Re: C++ float-to-int conversion can be undefined behavior
#55Earlier quoted context omitted.
I think this actually demonstrates why Rust's safety culture is what's crucial, not the safety technology they have built to enable that culture and which is relatively easier to duplicate. The natural instinct of humans is to deny problems. Their safety culture very strongly encourages Rustaceans encountering the equivalent issue [this really happened, you could write this nasty conversion bug in Rust 1.0 no problem…
Nitpick: Rust doesn't panic in this situation, it saturates (i.e., returns the largest possible value for the given integer type). Among other reasons, because a lot of existing programs that triggered this UB happened to work in practice, and would have experienced the panicking behavior as a severe regression. This case also shows the limits of Rust's safety culture; they knew about the problem for a long time, and…
It's interesting to consider that the same question would've surely come up during C and C++ language development, but that the answer is informed by the impact on the ecosystem, which was dramatically different when C, C++, and Rust were all being developed.
Re: C++ float-to-int conversion can be undefined behavior
#56Earlier quoted context omitted.
>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."
This is a semantic quagmire, and the threads on what undefined behaviour is are interminable. But just note this time around that correctness is not the same as conformity.
Re: C++ float-to-int conversion can be undefined behavior
#57Great, now converting a float to int will cause the C compiler to randomly reformat your hard drive... https://bugs.llvm.org/show_bug.cgi?id=49599
Only if you use floating point in your filesystem checks, which I really hope nobody does. How do you even store 3.14 bytes.
Re: C++ float-to-int conversion can be undefined behavior
#58Even worse, checking for overflow before casting can be tricky: https://stackoverflow.com/questions/526070/handling-overflow...
It's sad that comparison operators in C/C++ can lead to UB. Comparing unsigned to signed ints or comparing floats to ints is something the compiler could make work reliably at very little extra cost.
Re: C++ float-to-int conversion can be undefined behavior
#59Earlier quoted context omitted.
I think this actually demonstrates why Rust's safety culture is what's crucial, not the safety technology they have built to enable that culture and which is relatively easier to duplicate. The natural instinct of humans is to deny problems. Their safety culture very strongly encourages Rustaceans encountering the equivalent issue [this really happened, you could write this nasty conversion bug in Rust 1.0 no problem…
Nitpick: Rust doesn't panic in this situation, it saturates (i.e., returns the largest possible value for the given integer type). Among other reasons, because a lot of existing programs that triggered this UB happened to work in practice, and would have experienced the panicking behavior as a severe regression. This case also shows the limits of Rust's safety culture; they knew about the problem for a long time, and…
> Rust doesn't panic in this situation, it saturates
Yes sorry, in my head I'm thinking about what I'd want here because I do not like any of Rust's 'as' casts and in fact the thing I'd want here (TryInto) just does not exist on purpose for this reason. I wonder if I've ever run into this, realised I can't write a TryInto and if so what did I end up doing - interesting.
Re: C++ float-to-int conversion can be undefined behavior
#60Today 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.
As someone that jumped into Java already in 1996, even though it was still interpreted, JIT would only come into early 2000's, there was another big factor, the standard library.
Contrary to what people think nowadays, trying to write portable C or C++ code in the 90's was still an adventure.
C compilers were still getting C89 compliance, and POSIX wasn't as portable as folks think.
C++ was even worse, C++ARM was the C++ version of K&R C, compilers were more diverse than nowadays, each with their own frameworks, and C++98 was still a few years away.
Alongside Perl with CPAN, it was a big batteries box. Python wasn't that relevant yet.