Compiling Rust with GCC: an update

Posted Sep 10, 2022 18:52 UTC (Sat) by rvolgers (guest, #63218)
In reply to: Compiling Rust with GCC: an update by calumapplepie
Parent article: Compiling Rust with GCC: an update

> Part of the idea is to stabilize rust: right now, there are no bugs in rustc, because the language is defined as what rustc says is valid. There's no standard for how rust should behave; the documentation is informative, not normative. There's no real way to know if the undocumented behavior you're optimizing around is undocumented because nobody bothered to, or undocumented because it'll change tomorrow.

In a multi-party standard you have to look at *multiple* code bases and then go through a mediation process involving multiple parties if you discover an underspecified area, whereas on Rust you can just go through the normal change process to update the documentation, the code, or both.

to post comments

Compiling Rust with GCC: an update

Posted Sep 10, 2022 20:33 UTC (Sat) by tialaramex (subscriber, #21167) [Link] (5 responses)

There are cases where we can look at what people did, which broke, and say "That was obviously not supported, you keep both halves". For example there was a case recently where some crates were like "Hey I bet Rust's networking related data structures are literally identical to the C structures, and so I can just point Linux C code doing low-level networking at the Rust structures and it'll work" and one day that stopped working. That was never guaranteed to work, nobody should have done that.

But on the other hand there are cases where people are obliged to guess Rust does something, that there's some behaviour, and yet Rust's docs are basically just a shrug emoji. No behaviour is specified. Suppose I have some 64 byte aligned structures. Lots of them actually. I can make pointers to them, Rust is OK with that. Now, Rust doesn't have pointer arithmetic like C, but what if I turn a pointer into an integer. (unsafe) Rust is OK with this too. Surely the bottom four bits of that integer (at least) are zero, right? That's how aligned pointers work. Well, Rust doesn't formally say so, but it feels reasonable. Now, what if I mask these bits off, and use them to store 4 flags. Now I have a pointer-sized value with a pointer *and* my four flags, hooray. To get the pointer back, surely I mask the bits off back to zero, and turn my integer back into a pointer. No harm done. Does that work? Historically Rust said well, we do not promise this is OK, but it's the only thing we offer that seems appropriate here, and it did work.

Today you have to be more careful, nobody warned you about this, beyond the general warning that what you were doing was "unsafe" but what you were doing might stop working. On some platforms. Or maybe not. You have to either obey Strict Provenance, or you need to say OK, I can't meet these requirements, I opt out of strict provenance and I'll take my chances with this PNVI exposure stuff, and in both cases that has consequences I won't summarise here and it could change.

Compiling Rust with GCC: an update

Posted Sep 10, 2022 21:12 UTC (Sat) by stephen.pollei (subscriber, #125364) [Link] (2 responses)

I watched a youtube video , RustConf 2022 - WHAT IF WE PRETENDED UNSAFE CODE WAS NICE, AND THEN IT WAS? by Aria Beingessner, that talked a little bit about "provenance" . Seems like some have reasons on why they want to make things in this area a bit more strict.

Compiling Rust with GCC: an update

Posted Sep 10, 2022 22:22 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

Yes, that's the work I'm talking about. Just watched it and I felt like Aria's analogy in that video was very strange, while https://faultlore.com/blah/tower-of-weakenings/ her blog entry was clearer to me, but that might just be different preferences.

Compiling Rust with GCC: an update

Posted Sep 11, 2022 0:56 UTC (Sun) by khim (subscriber, #9252) [Link]

> Seems like some have reasons on why they want to make things in this area a bit more strict.

It's simple yet pretty useful psychological trick: if you ask people to follow needlessly strict rules but promise to relax them later 90% (if not 99%) is people would be happy with them. No matter what rules would you invent. And you can talk to the tiny subset of people who want more relaxed rules and try to make them happy, too. If you try to make the rules precise then you can never reach acceptance from everyone.

Heck, the whole Rust building is built on top of that approach: that's what separation of safe and unsafe Rust does.

Compiling Rust with GCC: an update

Posted Sep 11, 2022 0:33 UTC (Sun) by khim (subscriber, #9252) [Link] (1 responses)

> Today you have to be more careful, nobody warned you about this, beyond the general warning that what you were doing was "unsafe" but what you were doing might stop working. On some platforms. Or maybe not. You have to either obey Strict Provenance, or you need to say OK, I can't meet these requirements, I opt out of strict provenance and I'll take my chances with this PNVI exposure stuff, and in both cases that has consequences I won't summarise here and it could change.

But how can multiple implementations help there? C and C++ do have multiple implementation, the do have ISO Standard (many ones, actually) yet to this very day nobody knows what can or can not be done with pointers.

I think this is the last attempt which tried to clarify the issue (and proposal to, you know, make compilers which actually obey the standard as published was explicitly rejected).

At least Rust developers never claimed that they have a normative documentation which explains how unsafe is supposed to work.

C and C++ pretend that they do have such documentation and there are even people who claim that Rust is deficient because of that!

IMNSHO informative documentation is better that something which claims to be a normative documentation which you couldn't use as such.

At least if documentation is informative you know you couldn't use it as a guide.

Compiling Rust with GCC: an update

Posted Sep 11, 2022 9:20 UTC (Sun) by tialaramex (subscriber, #21167) [Link]

https://open-std.org/JTC1/SC22/WG14/www/docs/n3005.pdf is the current state of TS 6010, the draft Technical Specification which is what happened to N2676

So, modulo crazy ISO problems, the C23 standard per se won't mandate this roughly PNVI-address exposed model, but there will be an ISO document separately specifying how this would work. The standard is... rough. But there is limited enthusiasm for figuring out all the fine details while it remains unclear if everybody will even implement it. This only starts to make sense once at least two major compilers (e.g. MSVC and GCC) implement it.

With TS6010 you get most of the optimisations people expect in a modern compiler, and which of course Rust is doing, but you can do a XOR doubly linked list in C, as one example of stunt pointer manipulation that some people still think is a good idea. Of course some optimisations are given up in your doubly linked list code to make this work, but you don't feel that loss in unrelated code.