https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41138
Vincent Lefèvre <vincent-gcc at vinc17 dot net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vincent-gcc at vinc17 dot net
--- Comment #5 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to Martin Sebor from comment #2)
> So all cases are equivalent to
>
> foo = foo & 65280;
>
> The result of the expression (foo & 65280) is an int (or unsigned int, long,
> unsigned long, depending on the suffix of the constant) which is converted
> to char (the type of the assignment expression). In all cases in the first
> test case, the value of the result is guaranteed to be representable in
> unsigned char. There is no overflow or slicing and the code is strictly
> conforming with safe semantics.
I don't think that the code is strictly conforming: if foo == 0, the result is
implementation-defined because a signed 0 may have two possible representations
if the integer representation is not two's complement. However, I doubt that
the warning is related to that, because this is not related to overflow.
> That said, a warning stating that foo &= 65280 always evaluates to zero
> might be useful in case the intent wasn't to clear the variable (otherwise
> the code could be rewritten as foo = 0).
There shouldn't be a warning by default for the case the result is always 0:
the value 65280 could come from a macro whose value depends on the build
context. This is the same thing with always true or always false comparisons
(one used to get a warning in the past, but this has been fixed, AFAIK).
