On Wed, Oct 16, 2024 at 4:29 PM Joseph Myers <josmy...@redhat.com> wrote: > > On Wed, 16 Oct 2024, Eric Gallager via Gcc wrote: > > > One thing about -Wtraditional is that it enables a lot of different > > messages, so I always thought it would make more sense as an umbrella > > warning that just enables a bunch of sub-warning flags. While many of > > the individual sub-warnings may no longer be relevant, some of them > > might still be useful for reasons besides compatibility with > > traditional C. > > A few are also controlled by other options (I'm not proposing doing > anything with -Wtraditional-conversion or -Wlong-long, for example). I > don't think any of the others are likely to be of use. > > "non-static declaration of %q+D follows static declaration" > "traditional C lacks a separate namespace for labels, identifier %qE > conflicts" > "traditional C rejects ISO C style function definitions" > "traditional C rejects string constant concatenation" > "traditional C rejects the unary plus operator" > "traditional C rejects automatic aggregate initialization" > "traditional C rejects initialization of unions" > "%<long%> switch expression not converted to %<int%> in ISO C" > "the meaning of %<\\%c%> is different in traditional C" > "the meaning of %<\\x%> is different in traditional C" > "the meaning of %<\\a%> is different in traditional C" > "suggest not using %<#elif%> in traditional C" > "traditional C ignores %<#%s%> with the %<#%> indented" > "suggest hiding %<#%s%> from traditional C with an indented %<#%>"
This is one of the things I tested when adding gcc.dg/pragma-diag-7.c in r8-787-g4287da829c9697: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=4287da829c9697c58131666447bf8f707bd8b635 > "traditional C rejects the %<%.*s%> suffix" Some coding style guidelines dislike suffixed constants; for example, see this passage from GCC's own README.Portability: Suffixes on Integer Constants ----------------------------- You should never use a 'l' suffix on integer constants ('L' is fine), since it can easily be confused with the number '1'. > "function-like macro %qs must be used with arguments in traditional C" This one just makes sense as a style guideline to me, and it would be good if GCC's own fix-it hint system paid attention to it, as per bug 81419: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81419 > "macro argument %qs would be stringified in traditional C" This one I added a test for in gcc.dg/pragma-diag-7.c due to having seen it in real code; see r8-4796-g34b81eb96cd1df: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=34b81eb96cd1df28d7f878bc1f3df607746507da > > If someone thinks one of these is desirable as a coding style warning > without regard for traditional C, please explain why. Or if you do have > code you'd like to build with both GCC 15 or later, and a pre-C89 > compiler, please give details. Such details are much more relevant than > pure speculation that maybe something could be of use to someone. > > -- > Joseph S. Myers > josmy...@redhat.com >
