Undefined Behavior in 2017
blog.regehr.org
Undefined Behavior in 2017
1–10 of 120 posts
Re: Undefined Behavior in 2017
#2How many of these 200+ undefined behaviours exist in more modern low-level languages, such as Rust and D?
Re: Undefined Behavior in 2017
#3How many of these 200+ undefined behaviours exist in more modern low-level languages, such as Rust and D?
None exist in (safe) Rust.
Re: Undefined Behavior in 2017
#4How many of these 200+ undefined behaviours exist in more modern low-level languages, such as Rust and D?
In Rust it's pretty limited. Here is the full list, from the Rustonomicron:
Dereferencing null or dangling pointers
Reading uninitialized memory
Breaking the pointer aliasing rules
Producing invalid primitive values:
dangling/null references
a bool that isn't 0 or 1
an undefined enum discriminant
a char outside the ranges [0x0, 0xD7FF] and [0xE000, 0x10FFFF]
a non-utf8 str
Unwinding into another language
Causing a data race
Re: Undefined Behavior in 2017
#5How many of these 200+ undefined behaviours exist in more modern low-level languages, such as Rust and D?
None exist in (safe) Rust.
Sometimes you hit undefined behavior in LLVM when compiling safe Rust, but that is considered a bug in the compiler. https://github.com/rust-lang/rust/issues/10184
Re: Undefined Behavior in 2017
#6Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.
Re: Undefined Behavior in 2017
#7Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.
Some UB depends on the input (out of bounds access is a popular example). Some UB is created during optimization passes, for example by inlining. It's hard to produce useful error messages.
Re: Undefined Behavior in 2017
#8Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.
Some undefined behaviours relate to runtime values. !iirc! signed 2+2 is safe but signed SIGNED_INT_MAX + 1 is not.
Re: Undefined Behavior in 2017
#9Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.
> Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.
Absolutely not. Many instances of UB depend on runtime values. (E.g. overflows, out-of-bounds shifts, etc. etc.)
Re: Undefined Behavior in 2017
#10Why don't compilers have an option to reject UB with an compiler error? Surely the compiler must know when it comes across a piece of source code whose semantic is undefined.
Some undefined behaviours relate to runtime values. !iirc! signed 2+2 is safe but signed SIGNED_INT_MAX + 1 is not.
But it is easy to give it a defined behavior on a particular architecture. For example, on x86-64, it can be defined to overflow just like unsigned does. The compiler can emit errors about the code if it is compiled to a different architecture where the same defined behavior is too expensive to implement.