Skip to content

Commit 3e9cbb5

Browse files
committed
clarify that CTFE remains consistent
1 parent b515180 commit 3e9cbb5

File tree

1 file changed

+1
-0
lines changed

1 file changed

+1
-0
lines changed

text/0000-const-ub.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -27,6 +27,7 @@ The answer is that in this case, the final value that is currently being execute
2727
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.
2828
No guarantees are made about this final value, and it can be different depending on host and target architecture, compiler flags, and more.
2929
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.
30+
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.
3031

3132
Note, however, that this means compile-time UB can later cause runtime UB when the program is actually executed:
3233
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.

0 commit comments

Comments
 (0)