Update definition of UB in the glossary #203
Conversation
Partially addresses #202 .
|
I don't understand why you rewrote the entire glossary entry. Most of the diff isn't relevant to #202 nor otherwise a clear improvement (in some ways it's actually worse than the current wording, I think). The only real additions seems to be concentrated the last two paragraph (UB not being forever and the more expansive description of what a compiler may do with a program that has UB). So, why not just add those points to the existing text instead of rewriting everything? |
I tried, but I wasn't able to add the clarification to the current definition because it does not precisely say what undefined behavior is. |
reference/src/glossary.md
Outdated
|
|
||
| A list of behavior considered undefined is available in the [Rust Language Reference](https://doc.rust-lang.org/reference/behavior-considered-undefined.html). | ||
|
|
||
| > **Note:** In practice, UB is a contract between the Rust source code and the implementation. |
There was a problem hiding this comment.
The implementation of what? I think this is your C++ standard mode showing. ;)
I find "compiler" much more understandable.
There was a problem hiding this comment.
Maybe. Is it only the compiler ? It is also a contract with the implementation of the abstract machine (e.g. miri, the hardware, etc.).
There was a problem hiding this comment.
I think so far in the UCG documents we have always talked about "the compiler"?
I agree the proper spec might have to be more careful with terminology. But we should be consistent at least. So probably best to keep saying "the compiler" and file an issue to maybe s/compiler/Rust implementation/ or so?
reference/src/glossary.md
Outdated
|
|
||
| Rust requires that *safe* Rust is not able to exhibit *undefined behavior* (see [soundness][soundness]). It is up to the implementation and `unsafe` Rust code to ensure that this is the case. | ||
|
|
||
| A list of behavior considered undefined is available in the [Rust Language Reference](https://doc.rust-lang.org/reference/behavior-considered-undefined.html). |
There was a problem hiding this comment.
Please keep the Nomicon link, I think it is useful to read this in both styles.
As long as both lists exist, I think we should link them both here.
There was a problem hiding this comment.
Currently the Nomicon link is way outdated. I'll keep both links, but maybe the nomicon should be updated to just refer to the language reference at some point.
There was a problem hiding this comment.
I just (over the last few weeks) updated both of them, and the lists should actually be in sync. Why do you say it is outdated?
maybe the nomicon should be updated to just refer to the language reference at some point.
Agreed, but for now this is the situation we got.
There was a problem hiding this comment.
I just (over the last few weeks) updated both of them, and the lists should actually be in sync. Why do you say it is outdated?
I didn't realize that the nomicon PR was already merged.
reference/src/glossary.md
Outdated
| > It can also do something different every time. | ||
| > | ||
| > It is backward compatible to change the specification from making no guarantees (UB) to guaranteeing something (not UB). | ||
| > That is, Rust source code is not allowed to rely on UB being UB forever. |
There was a problem hiding this comment.
Why is that part just a "note"?
|
Considering #202 (comment), I think putting the error state first here does not reflect our current consensus any more.
|
|
No, i'm going to try to come up with a way to explain the two different types of UB that are discussed there. |
|
While thinking about this I came up with the following introduction, which I think is a nice starting point:
|
|
Closing due to inactivity, though updating this definition along the lines of #202 (comment) is probably still a good idea. |
Partially addresses #202 .