YutongZhuu wrote:
> > > But still I feel generate a warning for this case went too far.
> >
> >
> > Yeah, that's probably right. Maybe for `-` on a signed operand, we should
> > just return the original range with the `NonNegative` flag cleared out, and
> > shouldn't add the extra bit for the `-128 -> 128` edge case. That's not
> > technically correct, but probably is more useful in practice.
>
> Hm. That change will reintroduce a false positive warning for:
>
> ```c++
> bool b(signed char c) {
> return -c >= 128;
> }
> ```
>
> ... that this patch fixed. But we don't produce a false positive for `0 - c
> >= 128`, so I still think what we ought to do here is to make `-c` behave the
> same way that `0 - c` does.
I don't think I can fix the problem without re-introducing the false positive
in ``TryGetExprRange``. By looking at the AST, the only difference is that
```c++
unsigned char b = -a
```
has a implCast to unsigned char right before the unary operator but the false
positive case does not. By the time that the expression is passed into
``TryGetExprRange``, the information about the implCast has already lost (And
I cannot find any APIs that is able to get the parent expression or something
like that). I think it would be better to re-introduce the false positive
because I think having the implicit-int-conversion warning sounds more
unacceptable. Or you have any other suggestions on differentiating between the
two cases?
https://github.com/llvm/llvm-project/pull/126846
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
