VaList: Allow VaList::arg to fetch bool values

[dlrobertson]

Summary

VaList::arg::<bool>() should work.

Description

According to <stdbool.h> false is 0 and true is 1. As long as our encoding of bool is the same, we should allow VaList::arg::<bool>(). Since we take care of types smaller than an int in the codegen, this should work.

Related to: #44930

CC @alexcrichton @joshtriplett

[alexreg]

Hmm, does bool have a platform-dependent size? If so, I suggest we define a (platform-dependent) type alias std::os::raw::c_bool, aliasing to the appropriate integer type.

[joshtriplett]

On Sun, Jan 20, 2019 at 07:22:45PM -0800, Alexander Regueiro wrote: Hmm, does `bool` have a platform-dependent size? If so, I suggest we define a (platform-dependent) type alias `std::os::raw::c_bool`, aliasing to the appropriate integer type.

That conversation already happened in another bug; last I heard, `bool` is guaranteed to match the C type.

[alexreg]

Great. So we can probably just make VaList::arg::<bool>() "work"...

[workingjubilee]

I don't believe we should do this. To start with, doing this is UB in C. We would be making up our own rules and hoping C doesn't contradict us later.

It is also a common mistake to believe you can pass arguments of integer types smaller than int, or float arguments smaller than double, because of C's pervasive argument promotion. This isn't what really happens, and trying to pass these arguments... and currently, you can do so, unchecked (see #61275 about that) can lead to unsoundness. An unsoundness that is essentially undetectable in current Rust, and which has occurred in actual Rust programs.

It might have seemed inconceivable that C would suddenly become more active but C23 very much has. We are actually lagging behind C on what are effectively a subclass of const generic types right now. That's utterly absurd. Anyway, considering those types do have subtly different promotion rules, the possibility that C suddenly contradicts us on some fine-pointed detail seems very real to me. We avoid that risk, and also make it easier to understand the actual behavior of varargs, if we simply hew exactingly to what actually happens.