UB in Rust vs C [LWN.net]

UB in Rust vs C

Posted Aug 14, 2024 21:11 UTC (Wed) by abatters (✭ supporter ✭, #6932)
In reply to: UB in Rust vs C by ralfj
Parent article: Standards for use of unsafe Rust in the kernel

Compilers have flags such as -fwrapv to turn some UB into well-defined behavior, in which case it should be safe to rely on the flag to do what it is supposed to do. For example, the kernel Makefile has:

KBUILD_CFLAGS += -fno-strict-aliasing

# disable invalid "can't wrap" optimizations for signed / pointers
KBUILD_CFLAGS += -fno-strict-overflow

to post comments

UB in Rust vs C

Posted Aug 15, 2024 6:45 UTC (Thu) by ralfj (subscriber, #172874) [Link] (3 responses)

Indeed, such flags are probably the main way that compilers promise to make things not UB that the standard says are UB. (In the case of `-fno-strict-aliasing`, unfortunately the resulting language is rather under-documented. At least in C++, the entire language rests on the idea of a typed memory object model, so it is very unclear what it even means to just disable strict aliasing. But that's a different question.)

In Rust, we don't have such flags, since they lead to code that is UB or not depending on how you compile it, which we consider to be a bad idea. Instead, we offer non-UB versions of the relevant operations that programmers can use explicitly, such as raw pointers (to get around the aliasing requirements associated with references) and `wrapping_offset` vs `offset` on pointers and `wrapping_add/sub/mul/...` on integers (though of course even plain `+` is never UB in Rust, but it is considered a bug when `+` overflows and using `wrapping_add` is how you mark this as not-a-bug).

UB in Rust vs C

Posted Aug 16, 2024 0:05 UTC (Fri) by tialaramex (subscriber, #21167) [Link] (2 responses)

> it is considered a bug when `+` overflows and using `wrapping_add` is how you mark this as not-a-bug

I assume Rust-for-Linux is in practice never compiled in debug mode, if so as we start to see some more Linux developers with C experience deciding to write some Rust it will be important to correct the C instinct to assume that adding N in the usual way "just wraps" because in practice adding N really does just wrap in Rust (because by default the optimized build wraps on overflow), but as you say it's a bug to overflow, you should explicitly write what you meant even though that produces the same machine code, it makes maintenance much more robust.

UB in Rust vs C

Posted Aug 16, 2024 9:20 UTC (Fri) by farnz (subscriber, #17727) [Link] (1 responses)

It's complicated, because Rust defines addition as "either wrap (in twos' complement if signed) or panic", and says that which of those behaviours you get is unspecified, just that it'll be one of those two. So, while it's a bug to depend on wrapping without using wrapping_add etc or Wrapping<T> to indicate that it's deliberate, it's not as bad as it is in C, where it's UB.

With that said, the kernel's current compiler flags for Rust include -C overflow-checks so that the chosen behaviour is locked at "panic", even in release mode, if the CONFIG_RUST_OVERFLOW_CHECKS option is set. Hopefully enough developers leave this at the current default that Rust for Linux code never actually has a dependency on wrapping behaviour that's not expressed in code.

UB in Rust vs C

Posted Aug 16, 2024 10:14 UTC (Fri) by tialaramex (subscriber, #21167) [Link]

Oh that's actually really good news, thanks