Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Concatenated if and preprocessor
Date: Fri, 14 Mar 2025 16:27:38 -0700
Organization: None to speak of
Lines: 91
Message-ID: <87o6y3i45x.fsf@nosuchdomain.example.com>
References: <vquuhg$34o8d$2@dont-email.me> <vr15ti$rtjs$1@dont-email.me>
	<86frjfsgtb.fsf@linuxsc.com> <vr1rni$1q6m7$1@dont-email.me>
	<86bju3s5vp.fsf@linuxsc.com> <87zfhniaij.fsf@nosuchdomain.example.com>
	<8634ffrzj0.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sat, 15 Mar 2025 00:27:39 +0100 (CET)
Injection-Info: dont-email.me; posting-host="65766d3f94e315a3ff32ef79be62617b";
	logging-data="2367577"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX180zk7d/dgKcpQxuMD4O6WT"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:K1skVDxE5gQr0DvrX5jDPcEI1rU=
	sha1:lX1ury1Mqf3hHRgdJ/3rbip16Pk=
Bytes: 5108

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 */