Re: Concatenated if and preprocessor

From	Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups	comp.lang.c
Subject	Re: Concatenated if and preprocessor
Date	2025-03-14 16:27 -0700
Organization	None to speak of
Message-ID	<87o6y3i45x.fsf@nosuchdomain.example.com> (permalink)
References	(2 earlier) <86frjfsgtb.fsf@linuxsc.com> <vr1rni$1q6m7$1@dont-email.me> <86bju3s5vp.fsf@linuxsc.com> <87zfhniaij.fsf@nosuchdomain.example.com> <8634ffrzj0.fsf@linuxsc.com>

Show all headers | View raw

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

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Concatenated if and preprocessor pozz <pozzugno@gmail.com> - 2025-03-13 16:44 +0100
  Re: Concatenated if and preprocessor David Brown <david.brown@hesbynett.no> - 2025-03-13 16:55 +0100
  Re: Concatenated if and preprocessor scott@slp53.sl.home (Scott Lurndal) - 2025-03-13 16:11 +0000
  Re: Concatenated if and preprocessor James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-13 12:07 -0400
  Re: Concatenated if and preprocessor Kaz Kylheku <643-408-1753@kylheku.com> - 2025-03-13 16:30 +0000
  Re: Concatenated if and preprocessor bart <bc@freeuk.com> - 2025-03-13 17:29 +0000
  Re: Concatenated if and preprocessor Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-13 14:37 -0700
    Re: Concatenated if and preprocessor Lynn McGuire <lynnmcguire5@gmail.com> - 2025-03-13 18:25 -0500
      Re: Concatenated if and preprocessor Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-14 09:26 -0700
  Re: Concatenated if and preprocessor James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-13 12:19 -0400
  Re: Concatenated if and preprocessor pozz <pozzugno@gmail.com> - 2025-03-14 13:02 +0100
    Re: Concatenated if and preprocessor David Brown <david.brown@hesbynett.no> - 2025-03-14 14:13 +0100
    Re: Concatenated if and preprocessor Dan Purgert <dan@djph.net> - 2025-03-14 13:44 +0000
    Re: Concatenated if and preprocessor Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-14 09:44 -0700
      Re: Concatenated if and preprocessor Richard Harnden <richard.nospam@gmail.invalid> - 2025-03-14 18:15 +0000
        Re: Concatenated if and preprocessor Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-14 13:40 -0700
          Re: Concatenated if and preprocessor Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-14 14:10 -0700
            Re: Concatenated if and preprocessor Richard Harnden <richard.nospam@gmail.invalid> - 2025-03-14 21:31 +0000
              Re: Concatenated if and preprocessor Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-14 15:29 -0700
                Re: Concatenated if and preprocessor David Brown <david.brown@hesbynett.no> - 2025-03-15 17:32 +0100
            Re: Concatenated if and preprocessor Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-14 15:57 -0700
              Re: Concatenated if and preprocessor Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-14 16:27 -0700
                Re: Concatenated if and preprocessor scott@slp53.sl.home (Scott Lurndal) - 2025-03-15 15:06 +0000
                Re: Concatenated if and preprocessor Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-03-15 08:49 -0700
                Re: Concatenated if and preprocessor scott@slp53.sl.home (Scott Lurndal) - 2025-03-15 17:28 +0000
            Re: Concatenated if and preprocessor David Brown <david.brown@hesbynett.no> - 2025-03-15 17:28 +0100
        Re: Concatenated if and preprocessor Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-03-15 07:03 +0000
    Re: Concatenated if and preprocessor Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-03-14 11:10 -0700
    Re: Concatenated if and preprocessor James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-03-14 23:20 -0400

csiph-web