Re: Concatenated if and preprocessor

On 14/03/2025 22:10, Keith Thompson wrote:

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.

It is normal for safety or reliability critical software to insist that all warnings are treated as errors.  This is essential to avoid missing warnings when using a build system - if you run "make" and you get warnings, running "make" again will appear to give a clean warning-free build.  So you use "warnings as errors" options to the compiler, at least once your project is somewhat stable in the development process.
But it is not normal to insist that /all/ compiler warnings are enabled - many compilers support a wide range of warnings, and many will be inapplicable to some code.  Coding standards don't usually go into enough detail of the use of a particular compiler to specify warnings exactly - and it would rarely be a good idea anyway if the standard should cover a range of different types of code.  More often, they are vague about warnings - "enable all standard warnings" or "make good use of appropriate compiler warnings", along with insisting that the build be warning-free to avoid missing anything.

 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.
 

This can be an inconvenience, yes - and sometimes during development or testing, it is appropriate to "cheat" temporarily like this, or by disabling the "all warnings are errors" flag for a while.  A development process should not be /too/ rigid!
It's common to use "(void) foo;" in final code too.  Usually you don't want code that creates a variable and then does not use it at all, so warnings there can be helpful, and typically mean you should fix something in the code (remove the variable, or use it).  But for function parameters it is not uncommon that the signature must fit a particular form even though the implementation does not use all the parameters.  Casting the unused parameter to void is an idiomatic and clear way of indicating that the parameter is not used, without using implementation-specific features like "__attribute__((unused))".  (C23 gives two new alternatives - [[maybe_unused]], and leaving the parameter unnamed in the function definition.)
It can also be, IMHO, perfectly reasonable to add pragmas to disable particular warnings in code.  Sometimes you know that a particular bit of code will trigger a warning that you normally want enabled, and it would be ugly, unclear or inefficient to write the code in a way that avoids the warning.  Of course, such warning disable pragmas are not going to be portable.

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