3 ms·

I thought Rust doesn't have a specification, just a reference? So all of it is undefined behavior?

bruce343434 4y ago
I'd say all Rust is implementation defined
yccs27 4y ago
"Undefined behavior" is a term of art[0], with the specific meaning as mentioned in the article: The compiler is allowed to assume that UB never happens, and change the compiled code based on that assumption. Not "no one has written down a definition" or anything else. As the sibling comment points out, a contrasting term is "implementation-defined". Confusing the two is a common misconception when learning C++: You might expect "overflow is undefined behavior" to mean that there is no prescribed result and every compiler might do it differently, but each will produce results in its own consistent way. But that would be implementation-defined behavior; instead by doing unchecked addition, you tell the compiler that you know the addition will never overflow, and don't care at all about the overflowing case. [0] aka. "improper noun", see https://news.ycombinator.com/item?id=32673100 https://news.ycombinator.com/item?id=32673100
- yccs27 4y ago
  Followup to be precise: Undefined behavior in C++, of course, can have a definition set by the implementation. With the right switches, GCC will guarantee certain overflow behaviors. But a priori, the compiler is not bound by any guarantees.
planede 4y ago
IMO differentiating a specification and reference this way is just nitpicking. However it looks like that at least unsafe rust is underspecified regarding aliasing rules, therefore a bunch of unsafe rust is undefined behavior by definition. That is no authoritative text (whether reference or specification) defines the behavior of those programs. Key paragraph from the article: > Stacked Borrows is not part of the Rust spec, and is not the final word for aliasing-related UB in Rust. So there is still the chance that future revisions of this model can be made to better align with programmer intuition. The above code might get accepted because x2 is not actually being used to access memory. Or maybe &mut expr should only make such promises when used outside an unsafe block — but then, should adding unsafe really change the semantics of the program? As usual, language design is a game of trade-offs.

I'd say all Rust is implementation defined

"Undefined behavior" is a term of art[0], with the specific meaning as mentioned in the article: The compiler is allowed to assume that UB never happens, and change the compiled code based on that assumption. Not "no one has written down a definition" or anything else. As the sibling comment points out, a contrasting term is "implementation-defined". Confusing the two is a common misconception when learning C++: You might expect "overflow is undefined behavior" to mean that there is no prescribed result and every compiler might do it differently, but each will produce results in its own consistent way. But that would be implementation-defined behavior; instead by doing unchecked addition, you tell the compiler that you know the addition will never overflow, and don't care at all about the overflowing case. [0] aka. "improper noun", see https://news.ycombinator.com/item?id=32673100 https://news.ycombinator.com/item?id=32673100

yccs27 4y ago
Followup to be precise: Undefined behavior in C++, of course, can have a definition set by the implementation. With the right switches, GCC will guarantee certain overflow behaviors. But a priori, the compiler is not bound by any guarantees.

planede 4y ago

IMO differentiating a specification and reference this way is just nitpicking. However it looks like that at least unsafe rust is underspecified regarding aliasing rules, therefore a bunch of unsafe rust is undefined behavior by definition. That is no authoritative text (whether reference or specification) defines the behavior of those programs. Key paragraph from the article: > Stacked Borrows is not part of the Rust spec, and is not the final word for aliasing-related UB in Rust. So there is still the chance that future revisions of this model can be made to better align with programmer intuition. The above code might get accepted because x2 is not actually being used to access memory. Or maybe &mut expr should only make such promises when used outside an unsafe block — but then, should adding unsafe really change the semantics of the program? As usual, language design is a game of trade-offs.