Re: Concatenated if and preprocessor

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

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.

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.

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

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