-Wformat + typed enum class - difference with gcc

[LebedevRI]

Bugzilla Link	39369
Version	trunk
OS	Linux
CC	@AaronBallman,@dwblaikie,@zygoloid

Extended Description

https://godbolt.org/z/GX-Fqv

#include <stdio.h>

enum class Enum : unsigned short {
One,
};

void test(Enum e) {
printf("0x%04hx", e);
}

gcc:

: In function 'void test(Enum)': :8:12: warning: format '%hx' expects argument of type 'int', but argument 2 has type 'Enum' [-Wformat=] printf("0x%04hx", e); ^~~~~~~~~ ~ Compiler returned: 0

Clang is fine with that.

Who is wrong?

[AaronBallman]

I may be missing something, but I think everyone is right.

[expr.call]p12 says what to do when calling a varargs function like printf. It says that standard conversions happen (but those don't impact anything here except changing the lvalue to an rvalue). Since the argument still retains its enumeration type, we check to see if integral promotions apply and apply them if so.

[conv.prom] only talks about conversions for unscoped enumeration types and this is a scoped enumeration, so no integral promotion happens.

[dcl.enum]p10 only covers enumerators and unscoped enumeration types, so it also does not apply.

Based on that, I believe it is technically UB because the standard does not say that this is ill-formed as part of [expr.call] but it also neglects to say what should happen. So GCC is right to warn the user but Clang is also right to accept and "do something sensible".

[zygoloid]

This is a warning bug in Clang. Clang, GCC, and the standard agree that while unscoped enumerations get promoted to integral types by the default argument promotions, scoped enumerations do not (and require the corresponding scoped enumeration type to be used in the va_arg). To see this, try:

enum A {};
enum class B {};
void f(__builtin_va_list v) {
__builtin_va_arg(v, A);
}
void g(__builtin_va_list v) {
__builtin_va_arg(v, B);
}

Note that Clang and GCC warn on f but not on g (and GCC even compiles f into a ud2 instruction!).

However, Clang's format string checker seems to have a bug here, and is presumably converting enum types to their underlying types when checking arguments without regard for whether the enum type is scoped. So, while this is a quality-of-implementation issue, we should warn here.

Note in particular that 'e' will not necessarily even be passed in such a way that 'va_arg(v, int)' can retrieve it: the IR we emit for this call passes an i16, not an i32.

[AaronBallman]

So, while this is a quality-of-implementation issue, we should warn here.

Agreed.