Fix minor typo in const-ub RFC

This commit is contained in:
teor 2021-05-06 20:47:47 +10:00 committed by GitHub
parent 44580011f3
commit 5b81cdca4e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 1 additions and 1 deletions

View File

@ -26,7 +26,7 @@ The answer is that in this case, the final value that is currently being execute
For example, when UB arises while computing an array length, then the final array length can be any `usize`, or it can be (partially) uninitialized.
No guarantees are made about this final value, and it can be different depending on host and target architecture, compiler flags, and more.
However, UB will not otherwise adversely affect the currently running compiler; type-checking and lints and everything else will work correctly given whatever the result of the CTFE computation is.
In particular, when the same constant is used in two different crates, those crates will still definitely see the same value for that constant -- everything else would break the type system.
In particular, when the same constant is used in two different crates, those crates will still definitely see the same value for that constant -- anything else would break the type system.
Note, however, that this means compile-time UB can later cause runtime UB when the program is actually executed:
for example, if there is UB while computing the initial value of a `Vec<i32>`, the result might be a completely invalid vector that causes UB at runtime when used in the program.