https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #10 from gnzlbg <gonzalobg88 at gmail dot com> --- > But it constrains GCC in future, which leaving it unspecified does not. Documenting whether GCC's C _Bool has the same valid and trap representations as the target platform's ABI specifies is a trade-off: it does have a cost as you said, but it also adds value. The question is whether this trade-off is worth it. I am not a compiler expert, but using the same representation of _Bool as the platform's ABI allows GCC to avoid conversions on function arguments, return values, and when passing _Bools through memory. It appears to me that GCC would want to avoid doing these conversions anyways. An alternative here would be to, instead of guaranteeing this behavior, document the current behavior with a disclaimer that the behavior can change. So the cost of documenting this could be kept fairly small. Value-wise, if I want to cast an array of char to an array of _Bool, this guarantee allows me to check whether doing so will introduce undefined behavior, which I think is very valuable. So from my pov, documenting current behavior without guaranteeing it has almost zero cost, and adds a lot of value.
