10

Is there any way to achieve undefined behavior in Rust without using unsafe?

Of course, such behavior can be wrapped by a third-party library in a "safe" function so let's assume we're using only the standard one.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
passing_through
  • 1,778
  • 12
  • 24

1 Answers1

10

Absolutely, but any such case is a bug with Rust or the standard libary.

My favorite example is LLVM loop optimization can make safe programs crash, which actually occurs due to a poor interaction of Rust and LLVM semantics:

pub fn oops() {
    (|| loop {
        drop(42)
    })()
}

Compiled with optimizations on Rust 1.49.0, this produces the assembly:

playground::oops:
    ud2

such behavior can be wrapped by a third-party library in a "safe" function so let's assume we're using only the standard one

The standard library is a "third-party library", so I don't get the distinction.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
  • I meant std lib as something like "containing no bugs". As I can see, the answer is "no". – passing_through Jun 24 '20 at 16:19
  • 1
    @passing_through [`std` has sometimes contained UB-causing bugs.](https://www.ralfj.de/blog/2017/06/09/mutexguard-sync.html) That particular one was fixed, but you may be able to find other, more current examples by searching for [issues tagged *I-unsound* ](https://github.com/rust-lang/rust/labels/I-unsound%20%F0%9F%92%A5) on GitHub. – trent Jun 24 '20 at 16:29
  • Does it mean "any such case is a bug IN THE LIBRARY" (not in its user's code)? – passing_through Jun 24 '20 at 18:09
  • @passing_through Clarified. – Shepmaster Jun 24 '20 at 18:11
  • Are there any languages for which LLVM semantics are a good fit? It seems that LLVM semantics are based upon beliefs that (1) the C Standard is meant to specify all of the semantics that programmers should need to accomplish any and all kinds of tasks, rather than merely a core language which implementations intended for various tasks should extend to facilitate them, and (2) in cases where the C Standard specifies corner-case semantics that don't fit the LLVM abstraction model, it's a defect in the Standard, rather than a defect in the model. – supercat Jun 24 '20 at 18:42
  • 1
    @supercat It's a tradeoff. For Rust, LLVM is *so* good at optimization that the (pretty minor) divergence in semantics are well worth the gains in runtime performance. – Lambda Fairy Jun 25 '20 at 02:05
  • @LambdaFairy: From what I understand, Rust had to disable some of LLVM's optimizations because their semantics weren't compatible with those of Rust. LLVM might be a decent back-end if the proper "optimizations" are disabled, but I guess my question should be whether there are any languages for which the semantics of LLVM *with full optimizations enabled* would be a good fit. – supercat Jun 25 '20 at 17:52
  • Only C++, I guess. – Aloso Jun 26 '20 at 10:34
  • This has been fixed in 1.49 apparently! https://godbolt.org/z/GfTMvY – Geoxion Jan 15 '21 at 19:55
  • 1
    @LambdaFairy: I just managed to create another example of LLVM and Rust semantics disagreeing: https://godbolt.org/z/6cYE91 If `Y` happens to immediately follow `X`, something that could happen since the symbols are imported, and `i` is zero, `Y[0]` would be set to 4 but the function would return 3 (see line 17 of the assembly code). – supercat Jan 18 '21 at 23:26