Join GitHub today
Specify that `bool` is compatible with the `_Bool` C type. #954
FYI, the embedded world is chock-full of conflicting
I don't see much sense in
Actually, I agree with @petrochenkov with the
However, although rare, the
Back to topic: by the c99 standard, it is not clear what underlying type maps to
referenced this pull request
Mar 19, 2015
We discussed this at triage today, and the general feeling was that we probably don't want to commit to the representation of Rust's
As you've pointed out, just using a type alias probably won't work so well here, so we will likely need a new primitive type for this purpose if we are to add it. There are a number of possible routes here (such as a newtype scalar which canonicalizes on casts), but at this time though this is believe to be a backwards compatible change and we've decided to close this as postponed for now. Thanks for the RFC regardless, though!
Setting aside the question of whether we should have
I and others have claimed that C
In summary, Rust and C have identical representations for
Again, this only bears on whether it would be correct to equate Rust's and C's
The x86 and x86-64 ABIs that GCC uses for Linux are community-maintained forks of the original System V Application Binary Interface: Intel386 Architecture Processor Supplement, Fourth Edition. They both specify that C's
The Linux Standard Base had intended to be the authority that specifies the ABI to use on Linux, but it seems to be waning; Debian dropped LSB support in September 2015. For what it's worth, the LSB fails to specify the representation of
For the x86-64 architecture, Apple's ABI page cites what appears to be a copy of the GCC x86-64 ABI. This document contains the same language as quoted above for Linux: a
Apple's page on its x86 ABI says that
Then I get the following x86 machine code:
This loads the pointer
However, note that the C language specification requires
So although it's not written out, the OSX compiler behaves as if the x86 ABI places the same restrictions on the representation of
The MSDN page on Visual Studio's C++ ABI says that
I asked a friend to compile the following function with MSVC, without optimization:
This produced the following machine code:
The code for x86_64 is essentially the same.
As is the case with OSX above, the MSVC compiler feels free to assume that a value stored in a bool about which it has no other information is either zero or one. We can conclude that the values 0 and 1 are the only permitted representations for
@mahkoh: That's not the question I was trying to answer. I wanted to answer the question:
"Is it true that Rust's in-memory representation for
Both rust and clang use i1 to represent bools in scalar context and whatever LLVM uses as the memory representation (mostly i8) for the memory representation. Hence the question is reduced to whether clang is compatible with other C compilers. This is the case.
+1, If GCC/Clang sources show that "1 byte/0/1"
I'm curious what platforms supported by GCC or Clang don't use "1 byte/0/1"