On Tue, Apr 30, 2013 at 1:38 AM, Richard Trieu <[email protected]> wrote:
> The attached patch adds a new warning that triggers on mismatched header > guards. Typically, a header guard would look like: > > #ifndef HEADER_NAME_ > #define HEADER_NAME_ > > int foo = 42; > > #endif > > Occasionally, typos will cause the header guard to not function properly > but still compile, such as: > > #ifndef HEADER_NAME_ > #define HEDAER_NAME_ > > int foo = 42; > > #endif > > The two problem are: > 1) The header may be developed and used while only being included once > with no problems. Thus, it may take some time before the header guard > functionality is required. > 2) When the header is included twice, the error is "redefinition of 'foo'" > which obscures the actual source of the problem. > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > > Hi Richard, First of all, that certainly is a great idea! On the same line, during development I have encountered a second "stupid" pattern: // A.h #ifndef A_H #define A_H #endif // B.h #ifndef A_H #define A_H #endif // C.pp #include <B.h> #include <A.h> // some weird error about B not being defined, WHY ? It's typically hard to track down, because with the game of bringing includes in, whilst A is clearly being shadowed "by something" (at least, clear to a seasoned developer), it's pretty hard to tell WHO is shadowing A. So I wonder if in the same vein it would make sense to warn where two different files being included in the same translation unit are relying on the same header guards. I have no idea about that false-ratio this could bring in though :/ -- Matthieu
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
