[PATCH] D27607: [ubsan] Treat ObjC's BOOL as if its range is always {0, 1}

[Vedant Kumar via Phabricator via cfe-commits]

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