Suppressing "Parameter not used" Warning

On Tue, 4 Oct 2005 10:37:03 +0400, "Alexei A. Frounze"
<alexfru@chat.ru> wrote:

>"Thad Smith" <ThadSmith@acm.org> wrote in message
>news:4341e5ff$0$27319$892e0abb@auth.newsreader.octanews.com...
>...
>> I have used a void cast for some compilers.  For another, I was
>> successful with
>>
>> #define UNUSED(x)  if(x);
>
>Nice, though some clever compiler could warn here whether or not you're sure
>it's what you intend to do, whether or not this code has any effect.

Interesting idea, I'd never thought of that.  Though the lint I use
would surely complain about a "questionable use" of the semicolon
(even if it was removed from the macro itself)  unless you changed it
to something like

   #define UNUSED(x) if(x){}

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

Michael N. Moran wrote:
> David Brown wrote:
> 
>>     if (test()) {
>>         doThis();
>>         doThat();
>>     } else {
>>         doSomethingElse();
>>         doThat();
>>     }
>>
>> gcc will combine the two "doThat()" calls (which is good), and then 
>> warn that one of the "will never be executed", which is bad.
>>
>> If you know any good ideas to get working "will never be executed" 
>> warnings, even if it is "wait for gcc 4.1.x", I'd love to hear them.
> 
> 
> Hmmm. I tried this with a couple of GCC versions at default
> and -O[23] optimization levels (cross and native) and saw no
> such warning. What options/versions are you using?
> 

As is typical when you write something off the top of your head, my test 
case didn't work.  Additionally, you need the "-Wunreachable-code" 
warning flag on to get the warning.  A bit more testing showed that the 
following code gives an unwanted warning with msp430-gcc (3.2.3), but 
not for avr-gcc (3.4.1).  Both give a correct warning on test2().  So it 
looks like I've answered my own question - use gcc 3.4 or newer.  (gcc 
4.x for msp430 should not be too far off, I hope.)


unsigned char a, b, c, d;

void test(void) {
	if (a == 1) {
		b = 100;		// Should be no warning here
	} else if (a == 2) {
		b = 200;
	} else {
		b = 100;
	}
}

void test2(void) {
	if (c) {
		d = 10;
	} else if (!c) {
		d = 20;
	} else {
		d = 30;			// Should give warning here
	}
}

On 2005-10-03, Mark Borgerson <> wrote:
> In article <1128377419.771778.219560@g47g2000cwa.googlegroups.com>, 
> oldwolf@inspire.net.nz says...
>> 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; }
>> 
>> 
> Metrowerks Codewarrior has the
>
> #pragma unused (varname)
>
> construct to solve this problem.    I'm surprised that other compilers
> don't have the same facility.

They do (or something similar).

-- 
Grant Edwards                   grante             Yow!  My mind is making
                                  at               ashtrays in Dayton...
                               visi.com            

In article <43422bf9$1@news.wineasy.se>, 
david@westcontrol.removethisbit.com says...
> Mark Borgerson wrote:
> > In article <1128377419.771778.219560@g47g2000cwa.googlegroups.com>, 
> > oldwolf@inspire.net.nz says...
> > 
> >>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; }
> >>
> >>
> > 
> > Metrowerks Codewarrior has the
> > 
> > #pragma unused (varname)
> > 
> > construct to solve this problem.    I'm surprised that other compilers
> > don't have the same facility.
> > 
> > Mark Borgerson
> 
> The trouble with such pragmas is that they are completely non-portable. 
>   As Grant Edwards said, gcc has an equivalent (using an attribute, 
> which is gcc prefers over pragmas).  Often non-portability is not a 
> problem, since there are so many other non-portable aspects to typical 
> embedded systems (and in the case of gcc, it is at least portable to a 
> few dozen other gcc ports).
> 

I agree that such pragmas are  generally non-portable.  The

> #define UNUSED(x)  if(x){}

solution seems to be the best seen so far.  I tested it out with
CodeWarrior PalmOS (which I use for some M68K embedded work)  and
it issued no warnings and generated no code.  Can't ask for much
more than that!

In any case,  the fact that you get a warning from the compiler is
a good thing.   I have a lot more problems with porting structures
where I have to worry about packing and endian problems---and where
the compiler hasn't a clue what the code on the other end of the
communications line is doing!

Mark Borgerson

pete <pfiland@mindspring.com> writes:
> 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.

But some compilers will issue a warning about the
"expression" result not being used...

"Everett M. Greene" <mojaveg@mojaveg.iwvisp.com> wrote in message
news:20051004.7946BC0.7A60@mojaveg.iwvisp.com...
> pete <pfiland@mindspring.com> writes:
...
> > 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.
>
> But some compilers will issue a warning about the
> "expression" result not being used...

OK, what if the seed is used in an expression containing a comma, to the
left side of the comma?

Or what if it's used in an expression as
(seed*0)
or
(seed&0)
or
(seed&&0)?
:)
Should the compiler grumble in these 3 latter cases?

Alex

iddw@hotmail.com (Dave Hansen) writes:

> Please note crosspost.  

Noted, thank you.  Responders please note that I am not
a regular reader of comp.arch.embedded.


> 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?

Just a suggestion:

    #define NOT_USED(v)  ((void)(&(v)?1:0))

On Tue, 4 Oct 2005 21:31:58 +0400, "Alexei A. Frounze"
<alexfru@chat.ru> wrote:

>"Everett M. Greene" <mojaveg@mojaveg.iwvisp.com> wrote in message
>news:20051004.7946BC0.7A60@mojaveg.iwvisp.com...
>> pete <pfiland@mindspring.com> writes:
[...]
>> >     seed;
>> > }
>> >
>> > So, I just make an expression statement out of seed
>> > and that seems to stop the warnings.
>>
>> But some compilers will issue a warning about the
>> "expression" result not being used...
>
>OK, what if the seed is used in an expression containing a comma, to the
>left side of the comma?

Depends.  What's on the right side on the comma?  Is the comma
expression cast to void?

>
>Or what if it's used in an expression as
>(seed*0)
>or
>(seed&0)
>or
>(seed&&0)?
>:)
>Should the compiler grumble in these 3 latter cases?

Many compilers won't, but some will, and lint certainly will, unless
the expression is cast to void.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.

"Dave Hansen" <iddw@hotmail.com> wrote in message
news:1128453424.692e65550d080b6df6b829b39cef8b14@teranews...
> On Tue, 4 Oct 2005 21:31:58 +0400, "Alexei A. Frounze"
> <alexfru@chat.ru> wrote:
>
> >"Everett M. Greene" <mojaveg@mojaveg.iwvisp.com> wrote in message
> >news:20051004.7946BC0.7A60@mojaveg.iwvisp.com...
> >> pete <pfiland@mindspring.com> writes:
> [...]
> >> >     seed;
> >> > }
> >> >
> >> > So, I just make an expression statement out of seed
> >> > and that seems to stop the warnings.
> >>
> >> But some compilers will issue a warning about the
> >> "expression" result not being used...
> >
> >OK, what if the seed is used in an expression containing a comma, to the
> >left side of the comma?
>
> Depends.  What's on the right side on the comma?  Is the comma
> expression cast to void?

I don't know. It was just an idea...

> >Or what if it's used in an expression as
> >(seed*0)
> >or
> >(seed&0)
> >or
> >(seed&&0)?
> >:)
> >Should the compiler grumble in these 3 latter cases?
>
> Many compilers won't, but some will, and lint certainly will, unless
> the expression is cast to void.

No, my point was that to make it a part of the expression whose value *is*
used but happens to be unaffected by seed being multiplied by 0 or anded
with 0.

Alex

On Tue, 4 Oct 2005 23:23:39 +0400, "Alexei A. Frounze"
<alexfru@chat.ru> wrote:

[...]
>
>No, my point was that to make it a part of the expression whose value *is*
>used but happens to be unaffected by seed being multiplied by 0 or anded
>with 0.

Oh, OK, I understand now.  I expect there's a good chance it will
work.  But it's kind of hard to hide behind a macro.

Regards,

                               -=Dave
-- 
Change is inevitable, progress is not.