Forums

Suppressing "Parameter not used" Warning

Started by Dave Hansen October 3, 2005
Please note crosspost.  

Often when writing code requiring function pointers, it is necessary
to write functions that ignore their formal parameters.  For example,
a state machine function might take a status input, but a certain
error-handling state might ignore it:

   typedef void (*State_Fn)(uint8_t);

   void error_state(uint8_t status)
   {
      NOT_USED(status);

      /* code handling error but ignoring status */
   }

In another group, a poster asked about defining a macro NOT_USED as
shown above to quiet the compiler warning.  His suggested
implementation was

   #define NOT_USED(p) ((void)(p))

In this particular case, he noted the compiler he was using would
generate the warning even in the presence of this macro.  I suggested
he use

   #define NOT_USED(p) ((p)=(p))

He was pleased that it worked, but was concerned that the former
implementation was more widely supported, and that the latter might
generate executable code.  I for one had never seen the former before,
though I've often seen the latter (usually not hidden behind a macro),
and I've never seen it actually generate code.  At least, not in the
last ten years or so.

So I'm curious.  Which form (if either) is more common?  Are there any
implementations that will generate executable code for the latter?

Thanks,
   -=Dave

                               -=Dave
-- 
Change is inevitable, progress is not.
Dave Hansen wrote:
> > Please note crosspost. > > Often when writing code requiring function pointers, it is necessary > to write functions that ignore their formal parameters. For example, > a state machine function might take a status input, but a certain > error-handling state might ignore it: > > typedef void (*State_Fn)(uint8_t); > > void error_state(uint8_t status) > { > NOT_USED(status); > > /* code handling error but ignoring status */ > } > > In another group, a poster asked about defining a macro NOT_USED as > shown above to quiet the compiler warning. His suggested > implementation was > > #define NOT_USED(p) ((void)(p)) > > In this particular case, he noted the compiler he was using would > generate the warning even in the presence of this macro. I suggested > he use > > #define NOT_USED(p) ((p)=(p)) > > He was pleased that it worked, but was concerned that the former > implementation was more widely supported, and that the latter might > generate executable code.
Non executable code tends to generate warnings.
> I for one had never seen the former before, > though I've often seen the latter (usually not hidden behind a macro), > and I've never seen it actually generate code. At least, not in the > last ten years or so. > > So I'm curious. Which form (if either) is more common? Are there any > implementations that will generate executable code for the latter?
In distributions file for a sort timing program my distribution function arguments are of this form: (e_type *array, size_t n, long unsigned *seed) but only some of them use the seed for a PRNG. Others are like this: void sorted(e_type *a, size_t n, long unsigned *seed) { a += n; while (n-- != 0) { (*--a).data = n; } seed; } So, I just make an expression statement out of seed and that seems to stop the warnings. -- pete
In comp.lang.c Dave Hansen <iddw@hotmail.com> wrote:

> typedef void (*State_Fn)(uint8_t);
> void error_state(uint8_t status) > { > NOT_USED(status);
> /* code handling error but ignoring status */ > }
Why not just void error_state( uint8_t ) /* don't care about formal parameter */ { /* code */ } ? (I'm not enough of a guru to answer your real question.) -- Christopher Benson-Manica | I *should* know what I'm talking about - if I ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Christopher Benson-Manica wrote:
> In comp.lang.c Dave Hansen <iddw@hotmail.com> wrote: > > >> typedef void (*State_Fn)(uint8_t); > > >> void error_state(uint8_t status) >> { >> NOT_USED(status); > > >> /* code handling error but ignoring status */ >> } > > > Why not just > > void error_state( uint8_t ) /* don't care about formal parameter */ > {
Because that's not legal C. If it were, we obviously wouldn't need any hacks. You can do this in prototypes; in C++ you can also do it in definitions. Not in C, however. S.

Dave Hansen wrote On 10/03/05 10:13,:
> Please note crosspost. > > Often when writing code requiring function pointers, it is necessary > to write functions that ignore their formal parameters. For example, > a state machine function might take a status input, but a certain > error-handling state might ignore it: > > typedef void (*State_Fn)(uint8_t); > > void error_state(uint8_t status) > { > NOT_USED(status); > > /* code handling error but ignoring status */ > } > > In another group, a poster asked about defining a macro NOT_USED as > shown above to quiet the compiler warning. His suggested > implementation was > > #define NOT_USED(p) ((void)(p)) > > In this particular case, he noted the compiler he was using would > generate the warning even in the presence of this macro. I suggested > he use > > #define NOT_USED(p) ((p)=(p)) > > He was pleased that it worked, but was concerned that the former > implementation was more widely supported, and that the latter might > generate executable code. I for one had never seen the former before, > though I've often seen the latter (usually not hidden behind a macro), > and I've never seen it actually generate code. At least, not in the > last ten years or so. > > So I'm curious. Which form (if either) is more common? Are there any > implementations that will generate executable code for the latter?
First, there is no sure-fire way to prevent compilers from issuing diagnostics. The compiler is entitled to grouse about anything it chooses, provided it accepts code that does not actually contravene the Standard. It can warn about spellnig errors in comennts, or about inconsistent indentation levels. The requirement "No warnings from any compiler" is not ultimately tenable. FWIW, the `(void)p' formulation seems to be widespread. Even if a compiler complains about it, a human reader will see immediately that it was in fact the programmer's intent that `p' remain unused -- the programmer may have made a mistake, but at least it was not one of simple inattention. I don't think `(p)=(p)' is a wonderful idea. If `p' is volatile the generated code must perform both the read and the write. If `p' is `const' the compiler is required to issue a diagnostic, so you're no better off than when you started -- worse, if anything. Of course, `const'-qualified function parameters are fairly unusual and `volatile' parameters are exceedingly rare, but the possibilities exist. In any case, hiding the actual trickery behind a NOT_USED macro seems a good idea: you can re-#define NOT_USED as part of your adaptation to each new compiler that comes along, using whatever compiler-specific dodge seems to work best. -- Eric.Sosman@sun.com
In article <1128348834.7e34f2c71121565d6e8683d1777b7524@teranews>,
Dave Hansen <iddw@hotmail.com> wrote:
> > In another group, a poster asked about defining a macro NOT_USED as > shown above to quiet the compiler warning.
An alternative would be to invoke the compiler using a flag or option that disables the unused variable/parameter warning. However, it's good practice to turn the warning back on every once in a while and see if any unexpected unused thingies have crept into the code.
Dave Hansen wrote:
> Please note crosspost. > > Often when writing code requiring function pointers, it is necessary > to write functions that ignore their formal parameters. For example, > a state machine function might take a status input, but a certain > error-handling state might ignore it: > > typedef void (*State_Fn)(uint8_t); > > void error_state(uint8_t status) > { > NOT_USED(status); > > /* code handling error but ignoring status */ > } > > In another group, a poster asked about defining a macro NOT_USED as > shown above to quiet the compiler warning. His suggested > implementation was > > #define NOT_USED(p) ((void)(p)) > > In this particular case, he noted the compiler he was using would > generate the warning even in the presence of this macro. I suggested > he use > > #define NOT_USED(p) ((p)=(p)) > > He was pleased that it worked, but was concerned that the former > implementation was more widely supported, and that the latter might > generate executable code. I for one had never seen the former before, > though I've often seen the latter (usually not hidden behind a macro), > and I've never seen it actually generate code. At least, not in the > last ten years or so. > > So I'm curious. Which form (if either) is more common? Are there any > implementations that will generate executable code for the latter? > > Thanks, > -=Dave > > -=Dave
I use the first version, a cast-to-void macro. It works fine for gcc (various ports).
On 2005-10-03, David Brown <david@westcontrol.removethisbit.com> wrote:

>> #define NOT_USED(p) ((void)(p)) >>[...] >> #define NOT_USED(p) ((p)=(p)) >>[...] >> >> So I'm curious. Which form (if either) is more common? Are there any >> implementations that will generate executable code for the latter?
> I use the first version, a cast-to-void macro. It works fine > for gcc (various ports).
Very slightly OT, but I just use gcc's __attribute__((unused)). I realize it's not-portable to other compilers, but... 1) In my applications so much of the code is platform-specific that it just doesn't matter. 2) I've used nothing but gcc for embedded work for the past 6 or 7 years anyway. -- Grant Edwards grante Yow! Will the third world at war keep "Bosom Buddies" visi.com off the air?
In comp.lang.c Skarmander <invalid@dontmailme.com> wrote:

> Because that's not legal C. If it were, we obviously wouldn't need any > hacks. You can do this in prototypes; in C++ you can also do it in > definitions. Not in C, however.
My apologies; I use C++, and this was a difference of which I was not aware. Thanks. -- Christopher Benson-Manica | I *should* know what I'm talking about - if I ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Dave Hansen wrote:
> In another group, a poster asked about defining a macro NOT_USED as > shown above to quiet the compiler warning. His suggested > implementation was > > #define NOT_USED(p) ((void)(p)) > > In this particular case, he noted the compiler he was using would > generate the warning even in the presence of this macro. I suggested > he use > > #define NOT_USED(p) ((p)=(p)) > > > So I'm curious. Which form (if either) is more common? Are there > any implementations that will generate executable code for the latter?
Yes, the compiler might warn that 'p' is assigned a value which is never used. And it might also warn about reading an uninitialized variable. One compiler I use has this definition: #define NOT_USED(junk) { (volatile typeof(junk))junk = junk; }