Add a type which is equivalent to _Bool in C99

[alexcrichton]

Postponed RFC

This type would have to ensure two aspects:

1. The size of the representation is the same as the backing compiler's representation.
2. Each value is only ever allowed to contain the integer 0 or 1.

This could possibly be done through a new c_bool primitive type in liblibc (not an alias) or perhaps a wrapper struct/wrapper newtype if we're able to enhance as semantics enough (for example).

[Timmmm]

Did this ever happen? What should I do if I'm wrapping a C library that uses bool (_Bool)?

Edit: Never mind; seems it is still in the works but according to this comment all compilers/systems that you'd care about make _Bool a single byte, which is compatible with Rust's bool.

[strega-nil]

I would argue that we should define Rust's bool to be equivalent to _Bool.

[Yamakaky]

Wouldn't it prevent the compiler to do things like pack 8 bool in a byte? Or does repr(C) would take care of that?

[eddyb]

@Yamakaky Packing like that would have to be opt-in because you can take references to any fields.

[Timmmm]

Well, I'm not a rust pro, but I'd be happy with a c_bool that is defined to match _Bool and lets you convert between Rust's native bool and c_bool using as. That way you don't need to have Rust's native bool follow some weird C 'an integer at least as big as blah' stuff.

[Amanieu]

There are basically 2 ways to define c_bool:

• The easy way: type c_bool = bool
• The hard way:

#[repr(i8)]
enum c_bool {
    c_false = 0,
    c_true = 1,
}

The first one is easier to use, but ties our representation of bool with that of _Bool. Both use the same underlying representation (1 byte which is either 0 or 1) for all supported platforms, but in theory (though very unlikely) a future platform may appear which uses a different representation for _Bool.

[strega-nil]

@Amanieu I think that tying our representation of bool to _Bool is better; too many people have written extern functions assuming that bool is equivalent, that to do otherwise would be a serious back-compat concern, but only on esoteric platforms where one may not have tested their code.

[le-jzr]

I feel like this issue needs to be resolved.

Currently there is no stable way to use _Bool in FFI, and as long as Rust bool and _Bool compatible by accident, indecision just means defaulting to @ubsan's solution (eventually, de facto use of bool for the purpose will prevent any changes to its representation without silently breaking all that code).

[strega-nil]

@le-jzr it's already de facto resolved (and basically de jure resolved). There's no way to change it without silently breaking a ton of code.