Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bugs You'll Probably Only Have in Rust

gankro.github.io

Post reply on HN
Print view View original

11–20 of 91 posts

Re: Bugs You'll Probably Only Have in Rust

#11

Post by dbaupp »

wyldfire wrote: post #8
Gankro wrote: post #6

Earlier quoted context omitted.

Re: parameterized unsafe -- I think it's been discussed and rejected, I don't remember where. I think it was mostly a matter of "yes this would be more powerful, but the complexity isn't worth it". Note that we sort of made a "new" kind of unsafe with the UnwindSafe trait: https://doc.rust-lang.org/std/panic/trait.UnwindSafe.html That's probably how we intend to solve these kinds of problem in the future. Re: aliasin…

> Someone will develop a version of asan/ubsan for Rust. This already happened (japaric [1]). But ASan won't save you from a bug due to optimization-because-I-assumed-these-locations-dont-alias (maybe TSan might?). [1] https://users.rust-lang.org/t/howto-sanitize-your-rust-code/...

As you say, none of the existing sanitisers catch Rust-specific problems, which is, I assume, what the parent meant by "for Rust". That said, they will likely catch many of the consequences of such violations, just not pinpoint the cause as precisely.

Re: Bugs You'll Probably Only Have in Rust

#12

Post by comex »

dbaupp wrote: post #11
wyldfire wrote: post #8

Earlier quoted context omitted.

> Someone will develop a version of asan/ubsan for Rust. This already happened (japaric [1]). But ASan won't save you from a bug due to optimization-because-I-assumed-these-locations-dont-alias (maybe TSan might?). [1] https://users.rust-lang.org/t/howto-sanitize-your-rust-code/...

As you say, none of the existing sanitisers catch Rust-specific problems, which is, I assume, what the parent meant by "for Rust". That said, they will likely catch many of the consequences of such violations, just not pinpoint the cause as precisely.

A Rust-specific sanitizer has been proposed, though. See my other reply (which I was in the middle of writing when this thread popped up, so I didn't see it):

https://news.ycombinator.com/item?id=14553679

Re: Bugs You'll Probably Only Have in Rust

#13

Post by dbaupp »

comex wrote: post #12
dbaupp wrote: post #11

Earlier quoted context omitted.

As you say, none of the existing sanitisers catch Rust-specific problems, which is, I assume, what the parent meant by "for Rust". That said, they will likely catch many of the consequences of such violations, just not pinpoint the cause as precisely.

A Rust-specific sanitizer has been proposed, though. See my other reply (which I was in the middle of writing when this thread popped up, so I didn't see it): https://news.ycombinator.com/item?id=14553679

That isn't yet an existing sanitizer. :)

It is definitely an important missing piece to bridge the gap to ASan/TSan, but it's still just a proposal/work in progress, not least because, AIUI, the precise rules it needs to enforce aren't yet entirely clear.

Re: Bugs You'll Probably Only Have in Rust

#15

Post by cpeterso »

kibwen wrote: post #9
wyldfire wrote: post #3

> Making unsafe a big scary "all bets are off" button is only compelling if most of our users don't need to use that button. Rust is trying to be a language for writing concurrent applications, so sharing your type between threads requiring unsafe would be really bad. It would be neat if we could decompose unsafe like so "unsafe[this_feature,that_feature] {}". The unqualified "unsafe" could still refer to a global "f…

> It would be neat if we could decompose unsafe like so "unsafe[this_feature,that_feature] {}" I sometimes feel the same way, but remember that the `unsafe` keyword only unlocks four additional features: 1. Dereferencing a raw pointer 2. Calling an unsafe function or method 3. Accessing or modifying a mutable static variable (and this might conceivably even be removed entirely someday) 4. Implementing an unsafe trait…

> 3. Accessing or modifying a mutable static variable (and this might conceivably even be removed entirely someday)

Mutable static variables removed or the unsafety of accessing them? Didn't Rust, at one early point, not allow mutable global variables?

Re: Bugs You'll Probably Only Have in Rust

#16

Post by steveklabnik »

cpeterso wrote: post #15
kibwen wrote: post #9

Earlier quoted context omitted.

> It would be neat if we could decompose unsafe like so "unsafe[this_feature,that_feature] {}" I sometimes feel the same way, but remember that the `unsafe` keyword only unlocks four additional features: 1. Dereferencing a raw pointer 2. Calling an unsafe function or method 3. Accessing or modifying a mutable static variable (and this might conceivably even be removed entirely someday) 4. Implementing an unsafe trait…

> 3. Accessing or modifying a mutable static variable (and this might conceivably even be removed entirely someday) Mutable static variables removed or the unsafety of accessing them? Didn't Rust, at one early point, not allow mutable global variables?

One of the compiler team members advocated for removing static mut entirely, but it didn't quite happen before 1.0. It's totally feasible to do so if const fn was stabilized, but it's not, so...

Re: Bugs You'll Probably Only Have in Rust

#18

Post by kibwen »

cpeterso wrote: post #15
kibwen wrote: post #9

Earlier quoted context omitted.

> It would be neat if we could decompose unsafe like so "unsafe[this_feature,that_feature] {}" I sometimes feel the same way, but remember that the `unsafe` keyword only unlocks four additional features: 1. Dereferencing a raw pointer 2. Calling an unsafe function or method 3. Accessing or modifying a mutable static variable (and this might conceivably even be removed entirely someday) 4. Implementing an unsafe trait…

> 3. Accessing or modifying a mutable static variable (and this might conceivably even be removed entirely someday) Mutable static variables removed or the unsafety of accessing them? Didn't Rust, at one early point, not allow mutable global variables?

`static mut` specifically. To elaborate, we obviously can't just go and remove it now due to our backwards-compatibility promise (at least not without a long deprecation period and a breaking major language version bump). Furthermore, even if we wanted to we actually can't completely replace `static mut` just yet: the intended replacement (using normal (non-`mut`) `static` variables that have `UnsafeCell`s in them) isn't completely usable until our constant-evaluation story is fleshed out further. And the unsafety would still be present one way or the other, but this would allow us to make the language simpler and make it a bit easier to explain the `unsafe` keyword (it would be a general extension of our policy to push complexity out of the language and into libraries whenever possible, which we believe makes the implementation easier to audit and results in a safer and more reliable language).

Re: Bugs You'll Probably Only Have in Rust

#19

Post by steveklabnik »

halestock wrote: post #17

Question for the rust folks - are there any features that wouldn't have been possible without "unsafe"? That is, if rust never had unsafe, would it have been fundamentally limited in any way? Or is it required for e.g. interoperability with C?

I'll give you the shortest example: in order to build an operating system in Rust for x86, you need to do this:

  let p = 0xb8000 as *mut u8;
VGA drivers use the memory mapped at 0xb8000 to drive the device. This creates a pointer, p, at that address.

In order to demonstrate this is safe (okay so unsafe isn't in this example, creating p is safe, but writing to/reading from it is not), a language would have to know:

1. That your code is running in kernel mode, that is the entire concept of ring 0 vs ring 3.

2. That the VGA spec specifies that location in memory.

Yeah, in _theory_, you could have a language that does this, but that'd tie your language so, so, so deeply to each platform, that it's not feasible.

This can be extrapolated to all kinds of other low-level things.

Re: Bugs You'll Probably Only Have in Rust

#20

Post by vvanders »

halestock wrote: post #17

Question for the rust folks - are there any features that wouldn't have been possible without "unsafe"? That is, if rust never had unsafe, would it have been fundamentally limited in any way? Or is it required for e.g. interoperability with C?

You pretty much nailed it with you question. FFI is by nature unsafe since C doesn't have lifetime semantics and traits around thread safety.
Post reply on HN