Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #391131 > unrolled thread

Concatenated if and preprocessor

Back to article view | Back to comp.lang.c

Contents

  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

Page 1 of 2  [1] 2  Next page →

#391131 — Concatenated if and preprocessor

Consider this code:

if (cond1) {
...
} else if (cond2) {
...
} else if (cond3) {
...
}

I want to activate every single if with a macro preprocessor. All the 
combinations are possible: only the first, only the second, only the 
third, the first and second... and so on.

What's the best method to have a clean code that is always compiled 
without errors?

[toc] | [next] | [standalone]

#391132

On 13/03/2025 16:44, pozz wrote:
> Consider this code:
> 
> if (cond1) {
> ...
> } else if (cond2) {
> ...
> } else if (cond3) {
> ...
> }
> 
> I want to activate every single if with a macro preprocessor. All the 
> combinations are possible: only the first, only the second, only the 
> third, the first and second... and so on.
> 
> What's the best method to have a clean code that is always compiled 
> without errors?

Could you give a short example of what you would want as the result of 
the pre-processing, just with a couple of conditions?

[toc] | [prev] | [next] | [standalone]

#391133

pozz <pozzugno@gmail.com> writes:
>Consider this code:
>
>if (cond1) {
>...
>} else if (cond2) {
>...
>} else if (cond3) {
>...
>}
>
>I want to activate every single if with a macro preprocessor. All the 
>combinations are possible: only the first, only the second, only the 
>third, the first and second... and so on.
>
>What's the best method to have a clean code that is always compiled 
>without errors?

Perhaps using switch instead of a series of if statements would
make the problem more tractable.

[toc] | [prev] | [next] | [standalone]

#391134

On 3/13/25 11:44, pozz wrote:
> Consider this code:
> 
> if (cond1) {
> ...
> } else if (cond2) {
> ...
> } else if (cond3) {
> ...
> }
> 
> I want to activate every single if with a macro preprocessor. All the 
> combinations are possible: only the first, only the second, only the 
> third, the first and second... and so on.
> 
> What's the best method to have a clean code that is always compiled 
> without errors?

The cleanest way to do this involves trusting the compiler to quietly
remove unused branches:

#ifdef COND1
    if (cond1) }
    } else
#endif

#ifdef COND2
    if (cond2) {
    } else
#endif

#ifdef COND3
    if (cond3 ) {
    }
#else
    ; // Alternatively, use {}
#endif

[toc] | [prev] | [next] | [standalone]

#391135

On 2025-03-13, pozz <pozzugno@gmail.com> wrote:
> Consider this code:
>
> if (cond1) {
> ...
> } else if (cond2) {
> ...
> } else if (cond3) {
> ...
> }
>
> I want to activate every single if with a macro preprocessor. All the 
> combinations are possible: only the first, only the second, only the 
> third, the first and second... and so on.
>
> What's the best method to have a clean code that is always compiled 
> without errors?

The best way is not to use the preprocessor to try to conditionally
generate syntax. Rather, use the preprocessor to control the
conditions. You can make the conditions appear false at compile
time, and he compiler will remove the code as dead code.

#if HAVE_FEATURE_RELATED_TO_COND1
#define cond1 real->expression[0].fun(arg)
#else
#define cond1 0
#endif

Thus if the feature is disabled, then if (cond1) becomes if (0).

There are reasons why this might not work, like the associated
code not compiling when the feature is disabled, due to missing
declarations.

Suppose we have to use the preprocessor to remove any combination of the
conditionals.


Firstly, let's (1) start the if/else ladder with a dummy if that is
always false, and (2) terminate it with a dummy else.

That way everything in between is consistenlty an "else if" item.

if (0) { /* empty */ }
else if (cond1) { ... code ...}
else if (cond2) { ... code ...}
else if (cond3) { ... code ...}
else { /* empty */ }

You see where this is going? We can now delete any combination of the
conditionals, including all of them.

if (0) { /* empty */ }
##if HAVE_FEATURE_REALTED_TO_COND1
else if (cond1) { ... code ...}
#endif
##if HAVE_FEATURE_REALTED_TO_COND2
else if (cond2) { ... code ...}
#endif
##if HAVE_FEATURE_REALTED_TO_COND2
else if (cond3) { ... code ...}
#endif
else { /* empty */ }


-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#391137

On 13/03/2025 15:44, pozz wrote:
> Consider this code:
> 
> if (cond1) {
> ...
> } else if (cond2) {
> ...
> } else if (cond3) {
> ...
> }
> 
> I want to activate every single if with a macro preprocessor. All the 
> combinations are possible: only the first, only the second, only the 
> third, the first and second... and so on.
> 
> What's the best method to have a clean code that is always compiled 
> without errors?


Comment out the macro of the conditions that are not needed:


   #define COND1
   #define COND2
   #define COND3

       if (0) {
       }
   #ifdef COND1
       else if (cond1) {
       }
   #endif

   #ifdef COND2
       else if (cond2) {
       }
   #endif

   #ifdef COND3
       else if (cond3) {
       }
   #endif

All 8 combinations (for 3 branches) should work including all disabled.

[toc] | [prev] | [next] | [standalone]

#391139

pozz <pozzugno@gmail.com> writes:

> Consider this code:
>
> if (cond1) {
> ...
> } else if (cond2) {
> ...
> } else if (cond3) {
> ...
> }
>
> I want to activate every single if with a macro preprocessor.  All the
> combinations are possible:  only the first, only the second, only the
> third, the first and second... and so on.
>
> What's the best method to have a clean code that is always compiled
> without errors?

    if ( ..bypass all further tests.. ) {
        // for a "skip all conditional segments" case (if needed)
        ...

 #if TEST_1
    } else if (cond1) {
        ...
 #endif

 #if TEST_2
    } else if (cond2) {
        ...
 #endif

 #if TEST_3
    } else if (cond3) {
        ...
 #endif

    } else {
        // for a "no conditional segment" ran case (if needed)
        ...
    }
    

Having said that, it's hard to imagine a scenario where doing
something like this is the best way to solve the higher level
problem.  It is almost certainly better to rethink the reasoning
that resulted in choosing this scheme, and find a way to avoid it.

[toc] | [prev] | [next] | [standalone]

#391147

On 3/13/2025 4:37 PM, Tim Rentsch wrote:
> pozz <pozzugno@gmail.com> writes:
> 
>> Consider this code:
>>
>> if (cond1) {
>> ...
>> } else if (cond2) {
>> ...
>> } else if (cond3) {
>> ...
>> }
>>
>> I want to activate every single if with a macro preprocessor.  All the
>> combinations are possible:  only the first, only the second, only the
>> third, the first and second... and so on.
>>
>> What's the best method to have a clean code that is always compiled
>> without errors?
> 
>      if ( ..bypass all further tests.. ) {
>          // for a "skip all conditional segments" case (if needed)
>          ...
> 
>   #if TEST_1
>      } else if (cond1) {
>          ...
>   #endif
> 
>   #if TEST_2
>      } else if (cond2) {
>          ...
>   #endif
> 
>   #if TEST_3
>      } else if (cond3) {
>          ...
>   #endif
> 
>      } else {
>          // for a "no conditional segment" ran case (if needed)
>          ...
>      }
>      
> 
> Having said that, it's hard to imagine a scenario where doing
> something like this is the best way to solve the higher level
> problem.  It is almost certainly better to rethink the reasoning
> that resulted in choosing this scheme, and find a way to avoid it.

It is code that must run on several platforms.

Lynn

[toc] | [prev] | [next] | [standalone]

#391175

Lynn McGuire <lynnmcguire5@gmail.com> writes:

> On 3/13/2025 4:37 PM, Tim Rentsch wrote:
>
>> pozz <pozzugno@gmail.com> writes:
>>
>>> Consider this code:
>>>
>>> if (cond1) {
>>> ...
>>> } else if (cond2) {
>>> ...
>>> } else if (cond3) {
>>> ...
>>> }
>>>
>>> I want to activate every single if with a macro preprocessor.  All the
>>> combinations are possible:  only the first, only the second, only the
>>> third, the first and second... and so on.
>>>
>>> What's the best method to have a clean code that is always compiled
>>> without errors?
>>
>>      if ( ..bypass all further tests.. ) {
>>          // for a "skip all conditional segments" case (if needed)
>>          ...
>>
>>   #if TEST_1
>>      } else if (cond1) {
>>          ...
>>   #endif
>>
>>   #if TEST_2
>>      } else if (cond2) {
>>          ...
>>   #endif
>>
>>   #if TEST_3
>>      } else if (cond3) {
>>          ...
>>   #endif
>>
>>      } else {
>>          // for a "no conditional segment" ran case (if needed)
>>          ...
>>      }
>>      >
>> Having said that, it's hard to imagine a scenario where doing
>> something like this is the best way to solve the higher level
>> problem.  It is almost certainly better to rethink the reasoning
>> that resulted in choosing this scheme, and find a way to avoid it.
>
> It is code that must run on several platforms.

Yes, I already understood that.  The point of my comment is
not to eliminate the preprocessor dependencies but to express
them in a more aesthetically pleasing way.

[toc] | [prev] | [next] | [standalone]

#391158

On 3/13/25 11:44, pozz wrote:
> Consider this code:
> 
> if (cond1) {
> ...
> } else if (cond2) {
> ...
> } else if (cond3) {
> ...
> }
> 
> I want to activate every single if with a macro preprocessor. All the 
> combinations are possible: only the first, only the second, only the 
> third, the first and second... and so on.
> 
> What's the best method to have a clean code that is always compiled 
> without errors?

The cleanest way to do this involves trusting the compiler to quietly
remove unused branches:

#ifdef COND1
    if (cond1) }
    } else
#endif

#ifdef COND2
    if (cond2) {
    } else
#endif

#ifdef COND3
    if (cond3 ) {
    }
#else
    ; // Alternatively, use {}
#endif

[toc] | [prev] | [next] | [standalone]

#391164

Il 13/03/2025 16:44, pozz ha scritto:
> Consider this code:
> 
> if (cond1) {
> ...
> } else if (cond2) {
> ...
> } else if (cond3) {
> ...
> }
> 
> I want to activate every single if with a macro preprocessor. All the 
> combinations are possible: only the first, only the second, only the 
> third, the first and second... and so on.
> 
> What's the best method to have a clean code that is always compiled 
> without errors?

You're right, a real example is better to define my problem.

I have a project that can be compiled in different ways, depending on 
the final product model (it's an embedded platform, it's a material 
device).
I have three models with different characteristics: MODEL_A, MODEL_B, 
MODEL_C. Three different builds that are managed at compile time by 
defining MODEL macro as MODEL_A, MODEL_B or MODEL_C.

For each model, I could have a different features set. FEATURE_1, 
FUTURE_2, FUTURE_3, ...

#if MODEL == MODEL_A
#  define FEATURE_1   1
#  define FEATURE_2   0
#  define FEATURE_3   0
#elif MODEL == MODEL_B
#  define FEATURE_1   0
#  define FEATURE_2   1
#  define FEATURE_3   0
#elif MODEL == MODEL_C
#  define FEATURE_1   1
#  define FEATURE_2   1
#  define FEATURE_3   1
#endif

Now, on the full-featured model (MODEL_C) I could write:

if (key == 1) {
   ...
} else if (key == 2) {
   ...
} else if (key == 3) {
   ...
} else {
   ...
}

However, for MODEL_A I should have:

if (key == 1) {
   ...
} else {
   ...
}

For MODEL_B I should have:

if (key == 2) {
   ...
} else {
   ...
}

This is the scenario.

I thought using if(0) or if(1), but many times I receive some warnings 
from the compiler (condition is always true or condition is always false).

[toc] | [prev] | [next] | [standalone]

#391165

On 14/03/2025 13:02, pozz wrote:
> Il 13/03/2025 16:44, pozz ha scritto:
>> Consider this code:
>>
>> if (cond1) {
>> ...
>> } else if (cond2) {
>> ...
>> } else if (cond3) {
>> ...
>> }
>>
>> I want to activate every single if with a macro preprocessor. All the 
>> combinations are possible: only the first, only the second, only the 
>> third, the first and second... and so on.
>>
>> What's the best method to have a clean code that is always compiled 
>> without errors?
> 
> You're right, a real example is better to define my problem.
> 
> I have a project that can be compiled in different ways, depending on 
> the final product model (it's an embedded platform, it's a material 
> device).
> I have three models with different characteristics: MODEL_A, MODEL_B, 
> MODEL_C. Three different builds that are managed at compile time by 
> defining MODEL macro as MODEL_A, MODEL_B or MODEL_C.
> 
> For each model, I could have a different features set. FEATURE_1, 
> FUTURE_2, FUTURE_3, ...
> 
> #if MODEL == MODEL_A
> #  define FEATURE_1   1
> #  define FEATURE_2   0
> #  define FEATURE_3   0
> #elif MODEL == MODEL_B
> #  define FEATURE_1   0
> #  define FEATURE_2   1
> #  define FEATURE_3   0
> #elif MODEL == MODEL_C
> #  define FEATURE_1   1
> #  define FEATURE_2   1
> #  define FEATURE_3   1
> #endif
> 
> Now, on the full-featured model (MODEL_C) I could write:
> 
> if (key == 1) {
>    ...
> } else if (key == 2) {
>    ...
> } else if (key == 3) {
>    ...
> } else {
>    ...
> }
> 
> However, for MODEL_A I should have:
> 
> if (key == 1) {
>    ...
> } else {
>    ...
> }
> 
> For MODEL_B I should have:
> 
> if (key == 2) {
>    ...
> } else {
>    ...
> }
> 
> This is the scenario.
> 
> I thought using if(0) or if(1), but many times I receive some warnings 
> from the compiler (condition is always true or condition is always false).
> 

How about :

	if (FEATURE_1 && key == 1) {
		...
	} else if (FEATURE_2 && key == 2) {
		...
	} else {
		...
	}

?

(You might prefer a switch to a list of if's, but that's a different issue.)

If you are still suffering from unwanted warnings (and don't want to 
disable the warning in question), can you post a godbolt.org link that 
shows some sample code giving the warning, along with the choice of 
compiler and flags you are using?  When people can duplicate the issue, 
it's a lot easier to give help than when your code is approximate, your 
compiler messages are vague, and we don't know details of the toolchain. 
  (Usually it does not matter if the toolchain is for the right target 
processor - you will generally get the same warnings for code for x86-64 
gcc, and godbolt has most versions of these available.)

[toc] | [prev] | [next] | [standalone]

#391166

On 2025-03-14, pozz wrote:
> Il 13/03/2025 16:44, pozz ha scritto:
>> Consider this code:
>> 
>> if (cond1) {
>> ...
>> } else if (cond2) {
>> ...
>> } else if (cond3) {
>> ...
>> }
>> 
>> I want to activate every single if with a macro preprocessor. All the 
>> combinations are possible: only the first, only the second, only the 
>> third, the first and second... and so on.
>> 
>> What's the best method to have a clean code that is always compiled 
>> without errors?
>
> You're right, a real example is better to define my problem.
>
> I have a project that can be compiled in different ways, depending on 
> the final product model (it's an embedded platform, it's a material 
> device).
> I have three models with different characteristics: MODEL_A, MODEL_B, 
> MODEL_C. Three different builds that are managed at compile time by 
> defining MODEL macro as MODEL_A, MODEL_B or MODEL_C.
>
> For each model, I could have a different features set. FEATURE_1, 
> FUTURE_2, FUTURE_3, ...
>
> #if MODEL == MODEL_A
> #  define FEATURE_1   1
> #  define FEATURE_2   0
> #  define FEATURE_3   0
> #elif MODEL == MODEL_B
> #  define FEATURE_1   0
> #  define FEATURE_2   1
> #  define FEATURE_3   0
> #elif MODEL == MODEL_C
> #  define FEATURE_1   1
> #  define FEATURE_2   1
> #  define FEATURE_3   1
> #endif


So are you saying that the features are potentially independent of the
models, or that "Model A" explicitly defines that only "FEATURE_1" is
available (and will never support the other two) ?

-- 
|_|O|_| 
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1  E067 6D65 70E5 4CE7 2860

[toc] | [prev] | [next] | [standalone]

#391178

pozz <pozzugno@gmail.com> writes:

> Il 13/03/2025 16:44, pozz ha scritto:
>
>> Consider this code:
>>
>> if (cond1) {
>> ...
>> } else if (cond2) {
>> ...
>> } else if (cond3) {
>> ...
>> }
>>
>> I want to activate every single if with a macro preprocessor.  All
>> the combinations are possible:  only the first, only the second, only
>> the third, the first and second... and so on.
>>
>> What's the best method to have a clean code that is always compiled
>> without errors?
>
> You're right, a real example is better to define my problem.
>
> I have a project that can be compiled in different ways, depending on
> the final product model (it's an embedded platform, it's a material
> device).
> I have three models with different characteristics:  MODEL_A, MODEL_B,
> MODEL_C.  Three different builds that are managed at compile time by
> defining MODEL macro as MODEL_A, MODEL_B or MODEL_C.
>
> For each model, I could have a different features set.  FEATURE_1,
> FUTURE_2, FUTURE_3, ...
>
> #if MODEL == MODEL_A
> #  define FEATURE_1   1
> #  define FEATURE_2   0
> #  define FEATURE_3   0
> #elif MODEL == MODEL_B
> #  define FEATURE_1   0
> #  define FEATURE_2   1
> #  define FEATURE_3   0
> #elif MODEL == MODEL_C
> #  define FEATURE_1   1
> #  define FEATURE_2   1
> #  define FEATURE_3   1
> #endif
>
> Now, on the full-featured model (MODEL_C) I could write:
>
> if (key == 1) {
>   ...
> } else if (key == 2) {
>   ...
> } else if (key == 3) {
>   ...
> } else {
>   ...
> }
>
> However, for MODEL_A I should have:
>
> if (key == 1) {
>   ...
> } else {
>   ...
> }
>
> For MODEL_B I should have:
>
> if (key == 2) {
>   ...
> } else {
>   ...
> }
>
> This is the scenario.
>
> I thought using if(0) or if(1), but many times I receive some
> warnings from the compiler (condition is always true or condition
> is always false).

So your question is not a language question but how to avoid
implemenation-specific warnings?  It would have been good to
explain that at the beginning.

My first suggestion is to just turn off the damn warning.  Any
compiler that gives a "condition always false" warning on 'if(0)'
is one best avoided.

Having said that, here is an alternative:

  for(  int just_once = 1;  just_once;  just_once = 0  ){
    #if FEATURE_1
      if(  condition_1  ){
        ...
        break;
      }
    #endif

    #if FEATURE_2
      if(  condition_2  ){
        ...
        break;
      }
    #endif

    #if FEATURE_3
      if(  condition_3  ){
        ...
        break;
      }
    #endif

      ... default code goes here ...

  }

Test compiles at optimization level -O1 shows gcc and clang are both
smart enough to optimize the for(...) out of existence, leaving
just the enabled if() sections.

[toc] | [prev] | [next] | [standalone]

#391184

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

... ?

[toc] | [prev] | [next] | [standalone]

#391194

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

[toc] | [prev] | [next] | [standalone]

#391195

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

[toc] | [prev] | [next] | [standalone]

#391198

On 14/03/2025 21: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? :-/

That would break a lot of macros :)

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

Hmm, clang with -Weverything is okay with:
   do { ... } while (0);

But not with:
   if ( 0 ) { ... }

But it's okay with:
   if ( (0) ) { ... }

I didn't know that was a thing, so I've learnt something new today, thanks.

[toc] | [prev] | [next] | [standalone]

#391206

Richard Harnden <richard.nospam@gmail.invalid> writes:

> On 14/03/2025 21: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? :-/
>
> That would break a lot of macros :)
>
>> [...]
>
> Hmm, clang with -Weverything is okay with:
>   do { ... } while (0);
>
> But not with:
>   if ( 0 ) { ... }
>
> But it's okay with:
>   if ( (0) ) { ... }

These examples illustrate why I have the reaction I do.  That
plus the lack of clarity as to what the OP's actual requirements
are explains my decision to use a for() rather than do/while(0).

[toc] | [prev] | [next] | [standalone]

#391245

On 14/03/2025 23:29, Tim Rentsch wrote:
> Richard Harnden <richard.nospam@gmail.invalid> writes:
> 
>> On 14/03/2025 21: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? :-/
>>
>> That would break a lot of macros :)
>>
>>> [...]
>>
>> Hmm, clang with -Weverything is okay with:
>>    do { ... } while (0);
>>
>> But not with:
>>    if ( 0 ) { ... }
>>
>> But it's okay with:
>>    if ( (0) ) { ... }
> 
> These examples illustrate why I have the reaction I do.  That
> plus the lack of clarity as to what the OP's actual requirements
> are explains my decision to use a for() rather than do/while(0).

I think your "for" solution would raise far more questions to any reader 
than idiomatic "do ... while (0)" would, or even if ((0)).  I really 
don't understand your reactions at all.

But I fully agree that it would be a lot easier to give the OP a good 
answer if he explained his requirements and situation better.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web