Clang warns on "wrong" header guard in "config.h"

[Charles Davis]

Hi,

I've been building Wine with Clang, and it (apparently, unlike GCC) produces warnings like this:

../../include/config.h:4:9: warning: 'WINE_CROSSTEST' is used as a header guard
      here, followed by #define of a different macro [-Wheader-guard]
#ifndef WINE_CROSSTEST
        ^~~~~~~~~~~~~~
../../include/config.h:5:9: note: '__WINE_CONFIG_H' is defined here; did you
      mean 'WINE_CROSSTEST'?
#define __WINE_CONFIG_H
        ^~~~~~~~~~~~~~~
        WINE_CROSSTEST

I tracked this down to these three lines in configure.ac:

AH_TOP([#ifndef WINE_CROSSTEST
#define __WINE_CONFIG_H])
AH_BOTTOM([#endif /* WINE_CROSSTEST */])

These lines generate what Clang thinks is the header guard for the "config.h" header, but we know that it isn't--that header AFAICT has never had an include guard, and __WINE_CONFIG_H is just there to indicate that it's been included. Should we change the __WINE_CONFIG_H macro to be a real header guard instead, or (as I'll admit it has been in the past) is Clang broken here? I'd imagine you guys don't want to rig configure to add -Wno-header-guard to CFLAGS if you can help it.

I will point out that lots of these warnings are generated when building with Clang, because (for obvious reasons) this particular header is included all over the place. It makes it harder to see real warnings (like the ones that caused AJ not to commit my last two patches). And please don't tell me to use GCC instead. I suspect that GCC might pick up a similar warning--there's been lots of cross pollination going on between GCC and Clang, so we might have to deal with this sooner or later--and I'd prefer sooner.

(I know the commit that added the WINE_CROSSTEST checks is from over 3 years ago, but this warning was only added recently to Clang, which is why I'm only bringing this up now.)

Chip

[Alexandre Julliard]

Charles Davis  writes:
> These lines generate what Clang thinks is the header guard for the
> "config.h" header, but we know that it isn't--that header AFAICT has
> never had an include guard, and __WINE_CONFIG_H is just there to
> indicate that it's been included. Should we change the __WINE_CONFIG_H
> macro to be a real header guard instead, or (as I'll admit it has been
> in the past) is Clang broken here?

You can try to add a real guard if it helps, but of course the
WINE_CROSSTEST ifdef has to remain.