Re: Concatenated if and preprocessor

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:

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).

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.

[...]

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.

On the project I'm thinking of, we used Visual Studio, preconfigured for
the project.  I could have changed the settings on my own system for a
one-time local build, but I never bothered.

[...]

(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).

As I said, the problem was a build script, not a coding standard.

The "configure" script tested for features by creating and compiling
small C programs.  My understanding at the time was that configure
would treat anything written to stderr during compilation as
an error, even if the compiler's exit status indicated success.
A particular version of gcc had a bug, fixed in the next point
release, that caused a spurious warning.  There was no gcc option
to disable just that warning.  I provided the wrapper script as
an alternative to the better solution of using a newer gcc, which
might not always be feasible.

I don't remember whether anyone actually used the wrapper script.

It might have been possible to change the tool's configuration to avoid
the error, but I never really looked into that.

This was all about 20 years ago.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */