-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Validity of booleans #70
Comments
Note that how
So saying that " If that's the case, we have to make the values of cc @mjbshaw |
No, we can't assume that. The C standard guarantees that
That would mean that an implementation has to ignore all other bits, such that |
While it's true that calling convention handling of bools needs to be compatible as well for FFI to work, I don't really see how that interacts with the memory representation in the way you suggest. Functions with C ABI can make any necessary adjustments between the memory representation and "argument passing representation" (for example, truncating a bool that's passed in to 8 bits) as part of the call/return handling. This already happens all over the place, e.g.
So the only choice/distinction I see here is whether calling convention compatibility is provided in addition to memory layout compatibility (similar to repr(C) newtypes vs repr(transparent) newtypes) without affecting memory layout, and as you say it's pretty clear that's indeed desired. |
Strictly speaking, there isn't anything Rust can say about the bit pattern of C's
Now the only question is whether there are other representations for |
For the unsafe code guidelines (UCG), I think it is enough to state that:
We don't really have to handle alternative representations for |
The issue with this is that C has no notion of a "validity invariant". |
A better way to phrase this might be:
C11 6.2.6.1p5 states:
That is, in C it is ok to materialize a |
Yeah that sounds more like the kind of terminology I expected. |
Presuming we continue to tie Rust UPDATE: And, to be clear, I'm not eager to revisit that topic. The lang team decision at the moment seems pretty clear. |
Closing as answered |
Discussing the validity invariant of booleans.
The obvious invariant is:
true
orfalse
.Is there any reason to allow any other value? In particular, this invariant means that no bit may be uninitialized.
As usual with bool, the remaining thing that can be bikeshed indefinitely is the interaction with FFI. Can we really assume that any function calling us from C only passes one of two possible bit patterns, on any platform? On which platforms can we be more specific and specify the actual bit patterns? AFAIK
false == 0x00
is given by the fact that C allows 0-initialziation of_Bool
. Can we say anything about the bit pattern oftrue
?The text was updated successfully, but these errors were encountered: