Suppressing "Parameter not used" Warning

[Dave Hansen]

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)(uin t8_t);

void error_state(uin t8_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]

On Tue, 4 Oct 2005 10:37:03 +0400, "Alexei A. Frounze"
<al*****@chat.r u> wrote:

"Thad Smith" <Th*******@acm. org> wrote in message
news:43******* *************** *@auth.newsread er.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 "questionab le 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.

[David Brown]

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

[Grant Edwards]

On 2005-10-03, Mark Borgerson <> wrote:

In article <11************ **********@g47g 2000cwa.googleg roups.com>,
ol*****@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))ju nk = 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

[Mark Borgerson]

In article <43********@new s.wineasy.se>,
da***@westcontr ol.removethisbi t.com says...

Mark Borgerson wrote:

In article <11************ **********@g47g 2000cwa.googleg roups.com>,
ol*****@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
implementati on 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))ju nk = 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

[Everett M. Greene]

pete <pf*****@mindsp ring.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)(uin t8_t);

void error_state(uin t8_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...

[Alexei A. Frounze]

"Everett M. Greene" <mo*****@mojave g.iwvisp.com> wrote in message
news:20******** ***********@moj aveg.iwvisp.com ...

pete <pf*****@mindsp ring.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

[Tim Rentsch]

id**@hotmail.co m (Dave Hansen) writes:

Please note crosspost.
Noted, thank you. Responders please note that I am not
a regular reader of comp.arch.embed ded.

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)(uin t8_t);

void error_state(uin t8_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))

[Dave Hansen]

On Tue, 4 Oct 2005 21:31:58 +0400, "Alexei A. Frounze"
<al*****@chat.r u> wrote:

"Everett M. Greene" <mo*****@mojave g.iwvisp.com> wrote in message
news:20******* ************@mo javeg.iwvisp.co m...

pete <pf*****@mindsp ring.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.

[Alexei A. Frounze]

"Dave Hansen" <id**@hotmail.c om> wrote in message
news:1128453424 .692e65550d080b 6df6b829b39cef8 b14@teranews...

On Tue, 4 Oct 2005 21:31:58 +0400, "Alexei A. Frounze"
<al*****@chat.r u> wrote:

"Everett M. Greene" <mo*****@mojave g.iwvisp.com> wrote in message
news:20******* ************@mo javeg.iwvisp.co m...

pete <pf*****@mindsp ring.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

[Dave Hansen]

On Tue, 4 Oct 2005 23:23:39 +0400, "Alexei A. Frounze"
<al*****@chat.r u> 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.