A deeper look into the GCC Rust front-end

Posted Oct 10, 2022 19:47 UTC (Mon) by mb (subscriber, #50428)
In reply to: A deeper look into the GCC Rust front-end by JoeBuck
Parent article: A deeper look into the GCC Rust front-end

I disagree.

Saying that unsafe disables checks is misleading.
All safety checks are still upheld. (Like borrow checking, for example)

It just adds *more* ways to manipulate data:
https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#u...

Saying that the unsafe keyword disables checks leads to nowcomers thinking that just adding unsafe disables basic safety guarantees. Which is not the case. If you write code that only accesses safe functions and features in an unsafe block, then all safety checks are still upheld.

A deeper look into the GCC Rust front-end

Posted Oct 10, 2022 21:54 UTC (Mon) by JoeBuck (subscriber, #2330) [Link] (11 responses)

The borrow checker will say that the operation of splitting a mutable slice into two non-overlapping mutable slices is unsafe. It is safe in the sense that after the operation completes, there's only one mutable reference to any element of the slice, but the borrow checker isn't smart enough to determine that. It will still run when there's a call to this code, taking as an assumption that the expected properties hold.

A deeper look into the GCC Rust front-end

Posted Oct 11, 2022 8:19 UTC (Tue) by mb (subscriber, #50428) [Link] (8 responses)

I don't get your point.
split_at_mut is a safe method. It doesn't require you to use an unsafe block.

And the unsafe keyword doesn't disable the borrow checker.

A deeper look into the GCC Rust front-end

Posted Oct 11, 2022 16:21 UTC (Tue) by JoeBuck (subscriber, #2330) [Link] (7 responses)

My point is that to implement that method, you must use unsafe Rust in the implementation, as the Rust documentation explains. It sounds like you are refusing to believe the Rust project's own book. Go read it, it explains the issue. The resulting method is safe.

A deeper look into the GCC Rust front-end

Posted Oct 11, 2022 17:08 UTC (Tue) by mb (subscriber, #50428) [Link]

Yes, the implementation of the method uses an unsafe block.
But that block doesn't disable any safety check.

> It sounds like you are refusing to believe the Rust project's own book.

Ehm, wat?

> Go read it, it explains the issue.

I read it a long time ago.
That's why I showed you the part which explains that unsafe doesn't disable any check and merely adds a handful of additional unsafe features.

If you write safe code that doesn't pass a Rust safety check, then merely adding `unsafe` to your code will never result in a running program. It will throw the exactly same errors as before.

A deeper look into the GCC Rust front-end

Posted Oct 11, 2022 18:02 UTC (Tue) by steveklabnik (guest, #114343) [Link] (4 responses)

As the person who co-authored the book...

https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html

> It’s important to understand that unsafe doesn’t turn off the borrow checker or disable any other of Rust’s safety checks: if you use a reference in unsafe code, it will still be checked. The unsafe keyword only gives you access to these five features that are then not checked by the compiler for memory safety. You’ll still get some degree of safety inside of an unsafe block.

A deeper look into the GCC Rust front-end

Posted Oct 11, 2022 18:26 UTC (Tue) by mb (subscriber, #50428) [Link] (3 responses)

> As the person who co-authored the book

Thanks for the book. It's one of the best technical books that I ever read.

A deeper look into the GCC Rust front-end

Posted Oct 11, 2022 22:23 UTC (Tue) by steveklabnik (guest, #114343) [Link] (2 responses)

You're welcome! Those are very kind words :)

Re: Rust-book kudos

Posted Oct 12, 2022 4:54 UTC (Wed) by buck (subscriber, #55985) [Link] (1 responses)

[Sorry if this is wandering grossly O/T]

As long as you are coming out of the woodwork here, let me also pile on:

Yes, a very good book, and one for which I and, I'm sure, many (thousands of) others are extremely grateful and obliged to you and Ms. Nichols. It's also one of the pillars on which the success of the language is founded/building, I have to believe, as I would find it hard to fathom there are many (any?) who have bypassed your book when they set out to do Rust, unless they want to miss out on the most thorough and comprehensive explanation of the language one can get, at its length, and, obviously, at its extreme of affordability and accessibility, and with its didactic rock-solidness and sweep, from people just kicking the tires on Rust to those who want to grasp the language implicitly. It is, in a word, a gateway drug.

Well, maybe I'm overstating some of that, and I'm not exactly a Rust developer myself, so maybe I don't have the read on it exactly right, but I'm guessing it is no exaggeration to say that the reason so many are undeterred by the knock on Rust that it's hard is because your book is right there to give them a pretty thorough understanding of what exactly Rust is, why the hard parts are the way they are and what you gain by way of recompense, and is welcoming and instructive in places where the compiler alone is a little less friendly a learning companion. At least it made me want to go program something up. (Alas, the only thing I've been able to find are the exercises in the Command-line Rust book, which were thoroughly engaging, but no particular itch of my own to scratch.)

Re: Rust-book kudos

Posted Oct 12, 2022 18:50 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

FWIW, I have done a fair amount of Rust development (somewhere in the order of 6-figure LoC) and maintenance and haven't read this book. But Rust also tickles my "maintainable code" itch like nothing else has and I read up on it fairly regularly. To be fair, I think the book was also a work-in-progress when I started poking Rust in earnest (I think it was post-1.0, but still in the single digits). My first attempts seem to have been in early 2014.

A deeper look into the GCC Rust front-end

Posted Oct 12, 2022 9:32 UTC (Wed) by farnz (subscriber, #17727) [Link]

The book does not say that the safety checks are "disabled" (your assertion). It says that in an unsafe block, you can use functionality that has weaker checks applied to it than safe Rust does - but if you don't use that extra functionality, you get exactly the same checking as any other Rust code.

And the reason for having some functionality gated behind "unsafe" is also explained; the Rust developers intend that the checks that apply to "safe" Rust guarantee that the code has no Undefined Behaviour, whereas no such guarantee is made for "unsafe" Rust.

It sounds like you need to read the Rust book again, before accusing people of refusing to believe it.

A deeper look into the GCC Rust front-end

Posted Oct 11, 2022 8:23 UTC (Tue) by farnz (subscriber, #17727) [Link] (1 responses)

The borrow checker is still running in the example code, though, and still says that all the properties the borrow checker enforces are correct in the code given in the example. It's just that you use functionality (ptr::add, slice::from_raw_parts_mut) that isn't available in Safe Rust, and that does things whose properties are not checked by the compiler.

I know this feels a lot like nit-picking, but the thing about Unsafe Rust is not that safety checks in Safe Rust get turned off - it's that when you use unsafe, you get access to extra features of Rust that are not safety checked. You still have all the same safety checks as any other Rust code - but the operations that require unsafe do so because some of the burden of checking safety is pushed onto the user.

A deeper look into the GCC Rust front-end

Posted Oct 22, 2022 10:32 UTC (Sat) by ssokolow (guest, #94568) [Link]

Not to mention that, if you abuse the unsafe constructs to do something like synthesizing a second mutable reference to something, it's not going to stop it from being instant undefined behaviour.

Inside or outside an unsafe block, the invariants of the safe Rust constructs must be upheld.