In Rust the decision about whether to pay for overflow checks or just wrap (because all modern hardware will just wrap if you don't check and that's cheaper) is a choice you can make when compiling software, by default you get checks except in release builds but you can choose checks everywhere, even in release builds or no checks even in debug.

By definition in Rust it's incorrect to overflow the non-overflowing integer types, and so if you intend say wrapping you should use the explicit wrapping operations such as wrapping_add or the Wrapping<T> types in which the default operators do wrap - but if you turn off checks then it's still safe to be wrong, just as if you'd call the wrapping operations by hand instead of using the non-wrapping operations.

That Dolby overflow code looks awkward enough that I can't imagine writing it in Rust even if the checking was off - but I wasn't there. However the reason it's on Project Zero is that it resulted in a bounds miss, and that Rust would have prevented anyway.

▲

codedokode 4 hours ago | parent | next [-]

> is a choice you can make when compiling software

That is not a solution because it means the code can behave differently, and expose vulnerability if wrong compilation settings are chosen.

The functions like "wrapping_add" have such a long names so that nobody wants to use them and they make the code ugly. Instead, "+" should be used for addition with exceptions, and something like "wrap+" or "<+>" or "[+]" used for wrapping addition.

That's how people work, they will choose the laziest path (the simplest function name) and this is why you should use "+" for safer, non-wrapping addition and make the symbol for wrapping addition long and unattractive. Make writing unsafe code harder. This is just basic psychology.

C has the same problem, they have functions checking for overflow, but they also have long and ugly names that discourage their use.

> modern hardware will just wrap if you don't check and that's cheaper

So you suggest that because x86 is a poorly designed architecture, we should adapt programing languages to its poor design? x86 will be gone sooner or later anyway.

Also, there are languages like JS, Python, Swift which chose the right path, it is only C and Rust developers who seem to be backwards.

▲

Asmod4n 5 hours ago | parent | prev [-]

__builtin_add_overflow Exists and it’s basically free on most CPUs out there.

	▲	tialaramex 4 hours ago \| parent [-]
		> __builtin_add_overflow Exists and it’s basically free on most CPUs out there. This is a very C-flavoured "solution". For those who haven't seen it this involves a pointer (!) and we're going to compute the addition, write the result to the pointed-at integer and then if that didn't fit and so it overflowed we'll return true otherwise false. The closest Rust analogy would be T::carrying_add which returns a pair to achieve a similar result. And yeah, checking is "basically free" unless it isn't, that's not different. If you haven't measured you don't know, same in every programming language. It's never been true that you can't write correct software in C or C++ the problem is that in practice you won't do so.