4 ms·

Rust actually has undefined behavior that is triggered by code outside of unsafe blocks, depending on how a result is used: https://github.com/rust-lang/rust/i

Rust actually has undefined behavior that is triggered by code outside of unsafe blocks, depending on how a result is used: https://github.com/rust-lang/rust/issues/33813 https://github.com/rust-lang/rust/issues/33813 This basically exposes LLVM's poison semantics (a kind of deferred UB) to Rust code: https://llvm.org/docs/LangRef.html#poisonvalues https://llvm.org/docs/LangRef.html#poisonvalues Code in another module that doesn't even know it is calling an unsafe function could trigger UB by using this.

TheDong 9y ago
Can you provide a specific example or playground link? It seems like you'd still have to dereference it, which is unsafe, yes?
- cwzwarich 9y ago
  If you read the linked LLVM documentation, you'll see that any LLVM instruction with side effects that depends on poison can trigger UB, e.g. a volatile store where the poison value is the stored value, not the address. I haven't tried very hard to write a seemingly safe Rust program using ptr:offset that LLVM will optimize into a crash. It's probably possible with a bit of work; this is basically C's signed overflow UB in a different guise, and programmer misunderstanding of that has caused serious bugs and security issues over the years.
  - mahkoh 9y ago
    ptr::offset is unsafe.
comex 9y ago
I think you misinterpreted the issue report you linked, which goes along with what Manishearth was saying about there being two meanings of “unsafe”. In this case, ptr::offset is declared as an unsafe fn - meaning only unsafe code can call it - because of the UB issue you mentioned. The reporter was asking to remove “unsafe”, arguing that Rust generally allows safe code to create arbitrary raw pointer values (but not deference them). Which is true, but only because that’s designed not to cause UB. ptr::offset can cause UB, so it has to remain an unsafe fn - lest it become “unsafe” in the sense of “potentially dangerous when called from safe code” - and the report was closed. Edit: There are some other known ways of causing UB from safe Rust code, but they’re considered bugs - and some longstanding ones are on the way to being fixed in the next few months, thanks to MIR borrow checking and saturating float->int casts.
- mahkoh 9y ago
  Segfault: #[link_section = ".data"] fn main() { }
- Manishearth 9y ago
  There are also ones which are considered "well, whatcanyado", like writing to /proc/self/mem. (link_section might be counted as one of these. or just tweaking your link flags)

TheDong 9y ago

Can you provide a specific example or playground link? It seems like you'd still have to dereference it, which is unsafe, yes?

cwzwarich 9y ago
If you read the linked LLVM documentation, you'll see that any LLVM instruction with side effects that depends on poison can trigger UB, e.g. a volatile store where the poison value is the stored value, not the address. I haven't tried very hard to write a seemingly safe Rust program using ptr:offset that LLVM will optimize into a crash. It's probably possible with a bit of work; this is basically C's signed overflow UB in a different guise, and programmer misunderstanding of that has caused serious bugs and security issues over the years.
- mahkoh 9y ago
  ptr::offset is unsafe.

comex 9y ago

I think you misinterpreted the issue report you linked, which goes along with what Manishearth was saying about there being two meanings of “unsafe”. In this case, ptr::offset is declared as an unsafe fn - meaning only unsafe code can call it - because of the UB issue you mentioned. The reporter was asking to remove “unsafe”, arguing that Rust generally allows safe code to create arbitrary raw pointer values (but not deference them). Which is true, but only because that’s designed not to cause UB. ptr::offset can cause UB, so it has to remain an unsafe fn - lest it become “unsafe” in the sense of “potentially dangerous when called from safe code” - and the report was closed. Edit: There are some other known ways of causing UB from safe Rust code, but they’re considered bugs - and some longstanding ones are on the way to being fixed in the next few months, thanks to MIR borrow checking and saturating float->int casts.

mahkoh 9y ago
Segfault: #[link_section = ".data"] fn main() { }
Manishearth 9y ago
There are also ones which are considered "well, whatcanyado", like writing to /proc/self/mem. (link_section might be counted as one of these. or just tweaking your link flags)