vsk added a comment.
In https://reviews.llvm.org/D27607#901882, @fjricci wrote:
> On platforms where `BOOL` == `signed char`, is it actually undefined behavior
> (or is it just bad programming practice) to store a value other than 0 or 1
> in your `BOOL`? I can't find any language specs suggesting that it is, and
> given that it's just a typedef for a `signed char`, I don't see why it would
> be.
Treating BOOL as a regular 'signed char' creates bad interactions with
bitfields. For example, this code calls panic:
struct S {
BOOL b1 : 1;
};
S s;
s.b1 = YES;
if (s.b1 != YES)
panic();
> If it's not actually undefined behavior, could we make it controllable via a
> separate fsanitize switch (like we have for unsigned integer overflow, which
> is also potentially bad practice but not actually undefined behavior).
The only defined values for BOOL are 'YES' and 'NO' {1, 0}. We've documented
that it's UB to load values outside of this range from a BOOL here:
https://developer.apple.com/documentation/code_diagnostics/undefined_behavior_sanitizer/invalid_boolean
Repository:
rL LLVM
https://reviews.llvm.org/D27607
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
