On Wed, 16 Oct 2024, Eric Gallager via Gcc wrote:
> > "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
That tests have been added / updated is not evidence that the feature is
useful.
> > "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'.
The relevant comment on this is
/* Traditional C only accepted the 'L' suffix.
Suppress warning about 'LL' with -Wno-long-long. */
and it doesn't warn about 'l' or 'L' (just 'u' or 'U') for integers. It
does warn about 'l' for floating point, but it also warns about 'L' there,
so it definitely is not a warning for this particular confusion issue.
> > "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
If someone is actually confused and expects the macro to be expanded,
they'll get an error anyway from not having the macro expanded. It seems
unlikely to me that cases such as in the testsuite
#define f(X) X
int f; // { dg-warning "function-like macro 'f' must be used with
arguments in traditional C .-Wtraditional." }
reflect what real code is likely to do (valid without the macro expansion
but still want a warning). After all, C has multiple namespaces of
identifiers within the language itself; this doesn't seem any more
relevant to me than the other -Wtraditional warning about labels
conflicting with variables of the same name.
> > "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
That doesn't look like real code that is confused about how macro
expansion works. It seems to be about the failure of #pragma GCC
diagnostic ignored "-Wtraditional" to disable a -Wtraditional warning.
Which says nothing about why anyone was using -Wtraditional in the first
place, but it would seem rather unlikely for binutils-gdb code from the
past 20 years to actually have any use for compatibility with pre-C89
compilers.
And this warning about string contents seems exactly the kind of thing
that can only possibly be of use if someone really does want to build code
with a pre-C89 compiler; it makes no sense whatever otherwise to have a
coding style rule about macro parameter names not appearing inside string
literals.
--
Joseph S. Myers
josmy...@redhat.com
