Re: Concatenated if and preprocessor

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

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

Richard Harnden <richard.nospam@gmail.invalid> writes:
>

On 14/03/2025 16:44, Tim Rentsch wrote:
>

   for(  int just_once = 1;  just_once;  just_once = 0  ){

>
Any reason not to say ...
>
do {
    ...
} while (0);
>
... ?

>
In fact using do/while(0) is what I first wrote.  But then
I thought, oh wait, what if an overzealous compiler gives
a warning because the while() expression is always false? :-/
>
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).

 Perhaps surprisingly, I
haven't found them to be terribly inconvenient.  I rarely ran into
a warning that was inordinately difficult to avoid.   I can see that
"clang -Weverything" would cause problems.

Yes, exactly my point.  "Lots of warnings" is not at all the same as
"all possible warnings".

The most common inconvenience was that if I experimentally commented
out some code, and it caused some variable not to be referenced,
the build would fail.  (I could just add `(void)foo;` to avoid that.)
To be clear, this was not code that I intended to commit.

Another question about coding standards is at what point in the
development process do they apply.  The rule in question here
says to _compile_ with all possible warnings active, presumably
meaning all compilations, not just those at checkin time.

I can imagine that there could be problems if a newer version of the
compiler produced new warnings, but we didn't often change compilers.

The two cardinal sins for giving error/warning options for a coding
standard are:  one, including an option whose meaning is not well
defined;  and two, including an option whose meaning changes over
time, either because of using a different compiler or because of
using a different version of the same compiler.  Saying it doesn't
happen often is no excuse;  developers should never agree to
requirements that mandate moving targets.

(In one obscure case, I wrote a wrapper script that could be
installed in $PATH as "gcc" that would invoke the real gcc and
filter out a particular warning.  The wrapper was necessary due to
the behavior of a build script, not to an explicit coding standard.)

A reasonable course of action under the circumstances, I expect.  At
the same time, it shows a shortcoming of the coding standard in
effect, if said standard says builds should not have any warnings
(and no exception is made for spurious warnings that occur because
of how builds are done).