On Mon, Jan 07, 2002 at 07:32:43PM -0800, Steve Fink wrote:
> would appeal more to other compilers. My only complaints with 
> 'if (0 || a) {}' are (1) I can easily see it getting optimized away
> and complaining anyway on a later gcc version or different compiler,

I was under the impression that compilers warn about unused variables
based on what they see in the original source code.
(I think that gcc can't warn on them at -O0, as it needs the trace flow
analysis that the optimiser turns on to detect unused variables)
I don't think that that warn based on the results of later simplification or
dead code removal.
Hence I'd be surprised if it generates a warning about an unused variable.
A warning about an empty block might be more likely. The initial version was

if (0 || a)
  ;

and that does give a warning about an empty statement in if.

I chose (0 || a) rather than just (a) to give multiple ways for different
optimisation strategies to come to the conclusion that the code can be
100% eliminated.

eg

a) expression simplification to if (0)
   remove dead block after if (0)

b) empty block, so don't need result of if statement, hence evaluate it just
   for side effects. Side effects of (0 || a) is zilch. Eliminate it

Of course, if some compiler doesn't like it, just do

#ifdef _symbol_for_awkward_compiler_
#define UNUSED (a) ...
#else
/* and so on */
#define UNUSED (a) ...
#endif

> and (2) it means you have to put all the UNUSED() after the variable
> declarations:
> 
> int f(int x, int y) {
>   int i = x + 1;
>   float f;
>   char* s = malloc(256);
>   UNUSED(y);
> 
>   /* body */
> }
> 
> ...but it's still the most portable of the alternatives I see, so I
> guess it should stay that way in wait of a better idea.

Yes, it's a bugger, and I don't like it. But I couldn't see a better way.

Nicholas Clark

Reply via email to