-Wheader-guard emits warning after #undef of guard macro

For the following test-case:
#ifndef FOO
#define FOO2

#undef FOO2
#endif

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

Is this appropriate or should it suppress warning in this case
since it's equivalent to the following: ?
#ifndef FOO
#endif

Thanks and Regards,
Prathamesh

Oops, forgot to include the mailing list. Sorry for the double email,
Prathamesh.

Prathamesh,

Can you tell me more about your use case? Is this a common pattern you
have encountered?

The header guard warning triggers on files with the following format:

// Start of file
#ifndef Macro1
#define Macro2
...
#endif // matches the #ifndef on the first line.
// End of file

and warns when Macro1 and Macro2 are close, but not exactly the same. The
warning already ignores cases where Macro1 and Macro2 are very different
(edit distance is over half the length). A similar exemption maybe be
warranted in this case too.

Prathamesh,

Can you tell me more about your use case? Is this a common pattern you have
encountered?

Um no, it's a contrived test case.

#ifndef Macro1
#define Macro2
Should warning be suppressed, if Macro2 gets undefined later in the
same header ?
eg: (they are literally named Macro1 and Macro2)
#ifndef Macro1
#define Macro2
...
#undef Macro2
#endif

Is it better to suppress the warning because it's equivalent to:
#ifndef Macro1
#endif

The header guard warning triggers on files with the following format:

// Start of file
#ifndef Macro1
#define Macro2
...
#endif // matches the #ifndef on the first line.
// End of file

and warns when Macro1 and Macro2 are close, but not exactly the same. The
warning already ignores cases where Macro1 and Macro2 are very different
(edit distance is over half the length). A similar exemption maybe be
warranted in this case too.

Thanks for pointing that out. However that's not the issue.
Could you please explain in short heuristics used by clang to decide
when the two macros are
"sufficiently" different ? Thanks :wink:

Prathamesh,

Can you tell me more about your use case? Is this a common pattern you have
encountered?

Um no, it's a contrived test case.

#ifndef Macro1
#define Macro2
Should warning be suppressed, if Macro2 gets undefined later in the
same header ?
eg: (they are literally named Macro1 and Macro2)
#ifndef Macro1
#define Macro2
...
#undef Macro2
#endif

Is it better to suppress the warning because it's equivalent to:
#ifndef Macro1
#endif

The header guard warning triggers on files with the following format:

// Start of file
#ifndef Macro1
#define Macro2
...
#endif // matches the #ifndef on the first line.
// End of file

and warns when Macro1 and Macro2 are close, but not exactly the same. The
warning already ignores cases where Macro1 and Macro2 are very different
(edit distance is over half the length). A similar exemption maybe be
warranted in this case too.

Thanks for pointing that out. However that's not the issue.
Could you please explain in short heuristics used by clang to decide
when the two macros are
"sufficiently" different ? Thanks :wink:

I meant to ask how is edit_distance computed. Found it here, thanks.
// The algorithm implemented below is the "clasic"
// dynamic-programming algorithm for computing the Levenshtein
// distance, which is described here:
//
// Levenshtein distance - Wikipedia

Could we maybe not warn if the the #ifndef and #define are separated by at least one empty line ?

For the following test-case:
#ifndef FOO
#define FOO2

#undef FOO2
#endif

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

Is this appropriate or should it suppress warning in this case
since it's equivalent to the following: ?
#ifndef FOO
#endif

Thanks and Regards,
Prathamesh
_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

Oops, forgot to include the mailing list. Sorry for the double email,
Prathamesh.

Prathamesh,

Can you tell me more about your use case? Is this a common pattern you have
encountered?

The header guard warning triggers on files with the following format:

// Start of file
#ifndef Macro1
#define Macro2
...
#endif // matches the #ifndef on the first line.
// End of file

and warns when Macro1 and Macro2 are close, but not exactly the same. The
warning already ignores cases where Macro1 and Macro2 are very different
(edit distance is over half the length). A similar exemption maybe be
warranted in this case too.

Could we maybe not warn if the the #ifndef and #define are separated by at
least one empty line ?

Also would it be a good idea, if clang warns on #undef of defined
control macro ?
example:
#ifndef FOO
#define FOO

#undef FOO
#endif

Warn that, control macro FOO gets undefined ?

> Prathamesh,
>
> Can you tell me more about your use case? Is this a common pattern you
have
> encountered?
Um no, it's a contrived test case.

Is this a reduction of a real problem? (This seems like a somewhat
legitimate complaint either way -- a macro that gets undefined probably
wasn't an include guard -- but if this actually occurs in the wild, it
would make this a higher priority issue.)

No, it was a contrived test case.
I added DefinedMacro->hasMacroDefinition() and it worked for me.

Index: PPLexerChange.cpp