False positive clang warning for `-Wassign-enum`

[llvmbot]

Bugzilla Link	20200
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@dwblaikie,@Weverything

Extended Description

Clang 3.5 is throwing a false positive warning for -Wassign-enum. I created a test case and ran:

typedef enum {RANDOM, IMMEDIATE, SEARCH} strategy_t;
int main() {
  strategy_t my_strategy = IMMEDIATE;
my_strategy = (my_strategy & ~(IMMEDIATE));

  my_strategy &= ~(IMMEDIATE);                                                                                  

  return 0;
}

The second

[llvmbot]

Clang 3.5 is throwing a false positive warning for -Wassign-enum. I created a test case and ran:

typedef enum {RANDOM, IMMEDIATE, SEARCH} strategy_t;
int main() {
  strategy_t my_strategy = IMMEDIATE;
  my_strategy = (my_strategy & ~(IMMEDIATE));
  my_strategy &= ~(IMMEDIATE);                                              
  return 0;
}

With the second my_strategy receiving the warning.

[zyv]

We have tons of patterns like this in our code (example from https://noamlewis.wordpress.com/2017/10/05/type-safe-enums-in-c-using-a-clang-plugin/):

enum Flags {
    FLAG_NONE = 0,
    FLAG_READ = 1,
    FLAG_WRITE = 2,
};
enum Flags do_something(void);
enum Flags do_something(void) {
    return FLAG_WRITE | FLAG_READ;
}

Clang doesn't like this:

clang -std=c11 -c /tmp/test.c -Weverything
/tmp/test.c:8:12: warning: integer constant not in range of enumerated type 'enum Flags' [-Wassign-enum]
    return FLAG_WRITE | FLAG_READ;
           ^
1 warning generated.

zaytsev@Yurys-MBP mc % clang --version
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: arm64-apple-darwin23.5.0

What's the position of clang developers on that? Is this a false positive?

I can understand that the result of the OR formally doesn't belong to the enum, but come on, this is one of the most pervasive patterns out there. How we are supposed to type things then in C?

[zyv]

FWIW, Andrew of GCC's fame thinks it's actually bogus for C:

Andrew Pinski @ 2015-08-21 23:20:42 UTC :

This warning is only useful for c++. C defines the full range of the underlying type of the enum for the enum while c++ has different rules.

Also I think this warning would be too noisy for c code and clang is wrong to implement it for c.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67314

[shafik]

CC @AaronBallman

This diagnostic does not look good to me, the enum should have enough bits to represent all the values and that should be capable of representing FLAG_WRITE | FLAG_READ

[AaronBallman]

I agree that it's a false positive to issue the diagnostic in C; the full range of the underlying type is available for use, unlike in C++. The code was added in 2012 without review, so I don't think this was considered.

I think (but have not verified) that other diagnostics already handle the case where the enumeration has a fixed underlying type (new in C23) where the assignment really would be out of bounds, so I think we can resolve this issue by skipping this diagnostic in C mode (when doing that work, someone should verify my assumptions though).