5 ms·
> However, if the author is arguing "Don't let the behavior of a naive enforcement of a Rust safety construct dictate how the optimized version should work" thi
by Rusky 7y ago
> However, if the author is arguing "Don't let the behavior of a naive enforcement of a Rust safety construct dictate how the optimized version should work" this seems like a more interesting position; but it's not clear that is the argument being made here.
This is exactly the point the author is arguing. The focus of all their work on UB is to make sure safe Rust can do all the optimizations we would like, by careful design of the abstract machine.
The immediately visible outcome of this work is a set of rules for what you can do in unsafe Rust, which taken together amount to this weird-looking abstract machine with its extra "uninitialized" values- something that can be implemented efficiently on real hardware assuming no UB.
The point here is that this abstract machine is a better, simpler, easier way to convince yourself whether or not an unsafe Rust program is well-defined, and that "what the hardware does" is too many layers removed to be a good tool here. You can think about "what the hardware does" another time, for other purposes, but trying to do so in this context is actively unhelpful.
- deleted 7y ago[deleted]
- archgoon 7y agoshrug. There's a difference between saying "This is a useful abstraction" and saying "understanding what assembly is generated is irrelevant in understanding what your program does so I will try to end all discussions where it comes up". I mean, the latter seems quite a bit more extreme, and is what the author explicitly is calling for.
- saagarjha 7y agoThe issue is that there are no guarantees on the generated assembly, and what your compiler of today may do is not necessarily what tomorrow's will.
- deleted 7y ago[deleted]
- archgoon 7y agoThere are most certainly guarantees on the generated assembly. The assembly has to enforce the abstract machine. I want to know how it does that. It can change, that's fine, it can be improved, it can be made worse, but the idea that the rust program doesn't run on physical hardware, as explicitly stated in the article, is pure bullshit.
- saagarjha 7y ago> The assembly has to enforce the abstract machine. Yes, but this only really means anything in the absence of undefined behavior. The compiler's job is generate assembly that produces the results that running the code in the abstract machine would, but the issue is that undefined behavior allows the abstract machine to do arbitrary things, so the compiler is free to generate whatever it likes in this case.
- archgoon 7y agoUm... this seems to be a stronger case then to ask what the hardware does. If the compiler can generate arbritray code, then the only recourse to understand what the resulting binary actually does is to look at the actual generated assembly. Understanding what the compiler was trying (and yes, this will change based on which compiler version you used) to do would presumably be helpful in that process. Sure, don't design around this behavior, but if you find yourself deploying an executable with undefined behavior, and you need to figure out the scope of the problem; this seems useful. I don't get this hostility to understanding the tools you're using.
- saagarjha 7y ago> the only recourse to understand what the resulting binary actually does is to look at the actual generated assembly Pretty much, yes. > I don't get this hostility to understanding the tools you're using. Don't take me the wrong way: I'm interested in how compilers work, but I accept the concession that I can only really understand their output when my program is free of undefined behavior. It would be nice to have the compiler try its best in the cases where I am violating the rules of the programming language, and often it will do so, but in general I cannot expect this and trying to do so will require making some sort of tradeoff with regards to performance or language power.