Re: Concatenated if and preprocessor

scott@slp53.sl.home (Scott Lurndal) writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>

It's because of examples like this that I am wary of rules
like "enable all warnings" and "treat any warning condition
as an error."  I recently ran across a set of coding standard
rules that included these rules:  not just /some/ warning
conditions, but ALL warning conditions.  I still don't know
if they were literally serious.  (And my understanding is
clang has a -Weverything option, which enables all warning
conditions that clang is able to test for, no matter how
silly.)

>
I've worked under such coding standards.

>
I'm guessing this comment is an overstatement, and that you have
worked with similar but not nearly as stringent coding standards.
The coding standard I was referring to above says "Compile with
all possible warnings active" (and then also says something about
addressing them).

>
Right, I didn't read closely enough.  Some (non-maximal) set of
warnings were enabled, and any warnings that resulted were treated
as fatal errors.

>
We build with -Wall.  It's been quite successful for us and
hasn't resulted in significant effort to maintain (granted
as we switch to newer versions of the compiler suite,   we
run into new warnings, but they're quite easy  to  address
either via code changes or #pragma).
>
The codebase runs well over two million SLOC and supports
gcc7 through gcc14.

Can you say which new warnings have been addressed via #pragma
(which I assume effectively means selective disabling)?