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

[pete]

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

[Christopher Benson-Manica]

In comp.lang.c Dave Hansen <id**@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.

[Skarmander]

Christopher Benson-Manica wrote:

In comp.lang.c Dave Hansen <id**@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.

[Eric Sosman]

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.

--
Er*********@sun.com

[Anonymous 7843]

In article <1128348834.7e34f2c71121565d6e8683d1777b7524@teran ews>,
Dave Hansen <id**@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.

[David Brown]

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

[Grant Edwards]

On 2005-10-03, David Brown <da***@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?

[Christopher Benson-Manica]

In comp.lang.c Skarmander <in*****@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.

[Old Wolf]

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

[Keith Thompson]

"Old Wolf" <ol*****@inspire.net.nz> writes:

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.

In fact, strictly speaking, this could invoke undefined behavior if p
really hasn't been initialized. Since it's a parameter (at least in
the context intended by the OP), that would happen only if the caller
passes an uninitialized value, so it would require some additional
smarts by the compiler to detect the problem.

On most real-world systems, this isn't going to cause any visible
problems, but it's possible that certain pointer values can cause a
trap when you try to load them into a register, even if there's no
attempt to dereference the value. The same could apply to any type
that can have trap representations.

Hiding this behind a NOT_USED macro is a good idea. The definition of
the macro can probably be made to vary depending on what system you're
on, using the usual twisty maze of #ifdefs method.

The ((p)=(p)) trick is ok if you make sure p is always initialized,
even to a meaningless value.

As others have mentioned, there is no portable way to control specific
warnings that will work across implementations.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark Borgerson]

In article <11**********************@g47g2000cwa.googlegroups .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))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

[Thad Smith]

Dave Hansen wrote:

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 have used a void cast for some compilers. For another, I was
successful with

#define UNUSED(x) if(x);

Thad

[Alexei A. Frounze]

"David Brown" <da***@westcontrol.removethisbit.com> wrote in message
news:43********@news.wineasy.se...
....

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

.... I use the first version, a cast-to-void macro. It works fine for gcc
(various ports).

Also: borland, watcom, a few less popilar ones. I don't remember about
msvc++. Probably too.
Alex

[Alexei A. Frounze]

"Thad Smith" <Th*******@acm.org> wrote in message
news:43***********************@auth.newsreader.oct anews.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.

Alex

[David Brown]

Mark Borgerson wrote:

In article <11**********************@g47g2000cwa.googlegroups .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))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).

[David Brown]

Grant Edwards wrote:

On 2005-10-03, David Brown <da***@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.

Also OT, but the warning that bugs me most with gcc is "warning: will
never be executed" on code that gets removed by the optimiser. If I've
written code that really cannot ever be executed, it's (almost
certainly) a mistake, so I want the compiler to tell me. But on code
like this:

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.

[Bill Davy]

"Dave Hansen" <id**@hotmail.com> wrote in message
news:1128348834.7e34f2c71121565d6e8683d1777b7524@t eranews...

Please note crosspost.

snip snip

void error_state(uint8_t /* status */)

I prefer to leave the argument there as it should make code easier to
comprehend. Commenting it out does not need comments.

[Michael N. Moran]

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?

--
Michael N. Moran (h) 770 516 7918
5009 Old Field Ct. (c) 678 521 5460
Kennesaw, GA, USA 30144 http://mnmoran.org

"So often times it happens, that we live our lives in chains
and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

[Flash Gordon]

Bill Davy wrote:

"Dave Hansen" <id**@hotmail.com> wrote in message
news:1128348834.7e34f2c71121565d6e8683d1777b7524@t eranews...

Please note crosspost.

snip snip

void error_state(uint8_t /* status */)

I prefer to leave the argument there as it should make code easier to
comprehend. Commenting it out does not need comments.

As noted by an earlier poster, that is not valid for a C function
definition (declaration yes, but not definition which is what was being
discussed).

If you want to discus what you do in C++ (or any language other than C)
then please remove comp.lang.c from the crosspost.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Dave Hansen]

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

"Thad Smith" <Th*******@acm.org> wrote in message
news:43***********************@auth.newsreader.oc tanews.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.

[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**********************@g47g2000cwa.googlegroups .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))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

[Mark Borgerson]

In article <43********@news.wineasy.se>,
da***@westcontrol.removethisbit.com says...

Mark Borgerson wrote:

In article <11**********************@g47g2000cwa.googlegroups .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))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

[Everett M. Greene]

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

[Alexei A. Frounze]

"Everett M. Greene" <mo*****@mojaveg.iwvisp.com> wrote in message
news:20*******************@mojaveg.iwvisp.com...

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

[Tim Rentsch]

id**@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))

[Dave Hansen]

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

"Everett M. Greene" <mo*****@mojaveg.iwvisp.com> wrote in message
news:20*******************@mojaveg.iwvisp.com.. .

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

[Alexei A. Frounze]

"Dave Hansen" <id**@hotmail.com> wrote in message
news:1128453424.692e65550d080b6df6b829b39cef8b14@t eranews...

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

"Everett M. Greene" <mo*****@mojaveg.iwvisp.com> wrote in message
news:20*******************@mojaveg.iwvisp.com.. .

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

[Dave Hansen]

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

[Thad Smith]

Alexei A. Frounze wrote:

"Thad Smith" <Th*******@acm.org> wrote in message
news:43***********************@auth.newsreader.oct anews.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.

Of course. The compiler in question (an old Keil compiler) gave a
warning for the void cast. I experimented and found that if(x);;
(another semicolon added after the macro invocation) generated no code
and no warning for that compiler. With no standard way to do this, we
are left to search about for implementation-dependent hacks.

Thad

[Ben Pfaff]

Thad Smith <Th*******@acm.org> writes:

[suppressed "parameter not used" warnings]

With no standard way to do this, we are left to search about
for implementation-dependent hacks.

Personally, I use an implementation-dependent feature that works
for the compilers I really care about. Why worry about trying to
suppress warnings on every compiler? It's not possible and you
could waste a lot of time trying.
--
"Large amounts of money tend to quench any scruples I might be having."
-- Stephan Wilms

[Grant Edwards]

On 2005-10-05, Ben Pfaff <bl*@cs.stanford.edu> wrote:

Thad Smith <Th*******@acm.org> writes:

[suppressed "parameter not used" warnings]

With no standard way to do this, we are left to search about
for implementation-dependent hacks.

Personally, I use an implementation-dependent feature that
works for the compilers I really care about. Why worry about
trying to suppress warnings on every compiler? It's not
possible and you could waste a lot of time trying.

Here in comp.arch.embedded, anybody with too strong an aversion
to implementation-dependent "hacks" is in for a lifetime of
frustration. There are just too many times when there simply
is no other way to accomplish that which must be accomplished.

Sure, standard and portable is always a good goal, but when
theres a 90+ percent chance the program is never going to be
compiled by a different compiler or run on a different
platform, there's a limit to how much utility should be
sacrificed and much effort should be expended to avoid usign
somethign like gcc's __attribute__(()) extension.

--
Grant Edwards grante Yow! My LIBRARY CARD
at expired...
visi.com

[Thad Smith]

Ben Pfaff wrote:

Thad Smith <Th*******@acm.org> writes:

[suppressed "parameter not used" warnings]

With no standard way to do this, we are left to search about
for implementation-dependent hacks.
Personally, I use an implementation-dependent feature that works
for the compilers I really care about.

Same here.
Why worry about trying to suppress warnings on every compiler?
I don't know. I'm certainly not advocating such worry.
It's not possible and you could waste a lot of time trying.

True. I typically only work with a few compilers and spend a little
time to customize such things as eliminating unneeded warnings, which
allows me to more easily find real problems. Turning off warnings,
ignoring them, or sprinkling non-standard code throughout is a last
resort for me. You may have other techniques that work better for
you.

Thad

[Albert van der Horst]

In article <1128616135.46050bff8a89745339c73052e1094284@teran ews>,
Thad Smith <Th*******@acm.org> wrote:

Ben Pfaff wrote:

Thad Smith <Th*******@acm.org> writes:

[suppressed "parameter not used" warnings]

> With no standard way to do this, we are left to search about
> for implementation-dependent hacks.
Personally, I use an implementation-dependent feature that works
for the compilers I really care about.

Same here.

Why worry about trying to suppress warnings on every compiler?

I don't know. I'm certainly not advocating such worry.

It's not possible and you could waste a lot of time trying.

True. I typically only work with a few compilers and spend a little
time to customize such things as eliminating unneeded warnings, which
allows me to more easily find real problems. Turning off warnings,
ignoring them, or sprinkling non-standard code throughout is a last
resort for me. You may have other techniques that work better for
you.

Indeed there is a much better technique.
Make clean code. Catch the warnings in a file.
Carefully inspect the warnings and head them.
Catch the warnings on the resulting cleaner code.
Now in the regression test, expect the warnings to remain
the same, i.e. make a diff with the file with the warnings
of the previous test.
Only act on warnings changes, indicative of new warnings.
Or on warnings that went away since you cleaned up your code.

Never ever becludge your code to suppress warnings.
They are there to ... warn you, which is a Good Thing.

Thad

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
al****@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst

[SM Ryan]

Albert van der Horst <al****@spenarnc.xs4all.nl> wrote:

# Indeed there is a much better technique.
# Make clean code. Catch the warnings in a file.

Recompile megabytes of source code because you change one
function declaration in a header file.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Raining down sulphur is like an endurance trial, man. Genocide is the
most exhausting activity one can engage in. Next to soccer.

[Thad Smith]

Albert van der Horst wrote:

In article <1128616135.46050bff8a89745339c73052e1094284@teran ews>,
Thad Smith <Th*******@acm.org> wrote:

True. I typically only work with a few compilers and spend a little
time to customize such things as eliminating unneeded warnings, which
allows me to more easily find real problems. Turning off warnings,
ignoring them, or sprinkling non-standard code throughout is a last
resort for me. You may have other techniques that work better for
you.

Indeed there is a much better technique.
Make clean code. Catch the warnings in a file.
Carefully inspect the warnings and head them.
Catch the warnings on the resulting cleaner code.
Now in the regression test, expect the warnings to remain
the same, i.e. make a diff with the file with the warnings
of the previous test.
Only act on warnings changes, indicative of new warnings.

That's an interesting idea! I suppose I should strip the line numbers
on the warnings so that code insertion/deletion doesn't trigger an
avalanche in the diff. It's time for a little scripting. I'll have
to give that a try. I could even fail a make if the warning file
changed.
Or on warnings that went away since you cleaned up your code.
Hmmm, the ominous disappearing warning!
Never ever becludge your code to suppress warnings.
The goal, of course, is to easily detect new warnings so that they can
be examined. Your approach is an interesting one.
They are there to ... warn you, which is a Good Thing.

Well, yes. That's why I try to hint to the compiler that its OK that
an if statement has a constant expression (because the macro it is in
takes various parameters).

Let's see, if I have conditional sections in my code, the warnings may
come and go as I change switches -- oh, dear! I suppose I should have
to have a separate expected warnings file for each configuration.

Thad

[S.Tobias]

In comp.lang.c Thad Smith <Th*******@acm.org> wrote:

Albert van der Horst wrote:

[snip]

Make clean code. Catch the warnings in a file.
Carefully inspect the warnings and head them.
Catch the warnings on the resulting cleaner code.
Now in the regression test, expect the warnings to remain
the same, i.e. make a diff with the file with the warnings
of the previous test.
Only act on warnings changes, indicative of new warnings.

That's an interesting idea! I suppose I should strip the line numbers
on the warnings so that code insertion/deletion doesn't trigger an
avalanche in the diff. It's time for a little scripting. I'll have
to give that a try. I could even fail a make if the warning file
changed.

This idea has been wandering around me for some time, too.
It could work like this: programmer puts #pramas in the code,
which contain verbatim quotes (or regexes, or identifires) of warnings
that are to be suppressed for the next line. The utility program (or
a script) calculates line numbers and produces a list of warnings
(with the line numbers) to cut out from the compiler output.
Like this:
#pragma nowarn t.c:%n: warning: comparison between signed and unsigned
if (u>s)

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Eric Sosman]

S.Tobias wrote On 10/13/05 17:19,:

In comp.lang.c Thad Smith <Th*******@acm.org> wrote:

Albert van der Horst wrote:

[snip]

Make clean code. Catch the warnings in a file.
Carefully inspect the warnings and head them.
Catch the warnings on the resulting cleaner code.
Now in the regression test, expect the warnings to remain
the same, i.e. make a diff with the file with the warnings
of the previous test.
Only act on warnings changes, indicative of new warnings.

That's an interesting idea! I suppose I should strip the line numbers
on the warnings so that code insertion/deletion doesn't trigger an
avalanche in the diff. It's time for a little scripting. I'll have
to give that a try. I could even fail a make if the warning file
changed.

This idea has been wandering around me for some time, too.
It could work like this: programmer puts #pramas in the code,
which contain verbatim quotes (or regexes, or identifires) of warnings
that are to be suppressed for the next line. The utility program (or
a script) calculates line numbers and produces a list of warnings
(with the line numbers) to cut out from the compiler output.
Like this:
#pragma nowarn t.c:%n: warning: comparison between signed and unsigned
if (u>s)

Ugh. Ugh ugh ugh.

First, while the use of warning-suppressing tags in the
code goes back at least to lint, using #pragma to express
them is a truly terrible idea. Somewhere there'll be a
compiler that actually recognizes "#pragma nowarn" and does
something with it -- for example, suppressing all warning
messages for the entire translation unit, or turning on
ARN (automatic name rewriting) NOW. Embed such tags in
specially-formatted comments that are linquistically inert,
not in constructs that might at any moment turn into toxic
chemicals and rot your program.

(Aside: I quite understand that the idea of "a different
compiler" may well be foreign to many projects of interest
in comp.arch.embedded. However, the thread is cross-posted
to comp.lang.c as well, where portability concerns appear to
carry somewhat more weight.)

Second, a far better way to suppress the warning you
mention is

if (u > (unsigned)s)

Sometimes it can be a bad thing for a "last resort" mechanism
to exist: it's too easy for people to give up searching for
the "first resort."

Finally, and it's been said before: The goal of turning
of ALL warnings from ALL compilers is ultimately futile,
because compilers are allowed to complain about anything
they feel like. "Warning: Source was modified at 2:37 AM;
sleep-deprived programmer may have made more mistakes than
usaul."

--
Er*********@sun.com

[S.Tobias]

In comp.lang.c Eric Sosman <er*********@sun.com> wrote:

S.Tobias wrote On 10/13/05 17:19,:

In comp.lang.c Thad Smith <Th*******@acm.org> wrote:

Albert van der Horst wrote:
[snip]

Make clean code. Catch the warnings in a file.
Carefully inspect the warnings and head them.
Catch the warnings on the resulting cleaner code.
Now in the regression test, expect the warnings to remain
the same, i.e. make a diff with the file with the warnings
of the previous test.
Only act on warnings changes, indicative of new warnings.
That's an interesting idea! I suppose I should strip the line numbers
on the warnings so that code insertion/deletion doesn't trigger an
avalanche in the diff. It's time for a little scripting. I'll have
to give that a try. I could even fail a make if the warning file
changed.

This idea has been wandering around me for some time, too.
It could work like this: programmer puts #pramas in the code,
which contain verbatim quotes (or regexes, or identifires) of warnings
that are to be suppressed for the next line. The utility program (or
a script) calculates line numbers and produces a list of warnings
(with the line numbers) to cut out from the compiler output.
Like this:
#pragma nowarn t.c:%n: warning: comparison between signed and unsigned
if (u>s)

Ugh. Ugh ugh ugh.

That's how great ideas die - someone says "ugh"... ;-)
First, while the use of warning-suppressing tags in the
code goes back at least to lint, using #pragma to express
them is a truly terrible idea. Somewhere there'll be a
compiler that actually recognizes "#pragma nowarn" and does
something with it -- for example, suppressing all warning
messages for the entire translation unit, or turning on
ARN (automatic name rewriting) NOW. :-)Embed such tags in
specially-formatted comments that are linquistically inert,
not in constructs that might at any moment turn into toxic
chemicals and rot your program.
That's true. All #pragmas (with a small exception) suffer from this
disease. OTOH the whole concept is subject to implementation behaviour
and is not (universally) portable. But I agree, it's always better to
avoid a mine-field, and take a quiet and safe path.
(Only, what if the compiler uses the same tags embedded in comments
for its own purposes, too?)

What might actually be bad in practice with #pragmas is that a
compiler might issue warnings about unrecognized #pragmas, thus
we'd be chasing our tail.

Let's make that:
/* $ nowarn: ... $ */
(Actually, only `$ nowarn: ... $' part is recognized by the utility.)

Second, a far better way to suppress the warning you
mention is

if (u > (unsigned)s)

Sometimes it can be a bad thing for a "last resort" mechanism
to exist: it's too easy for people to give up searching for
the "first resort."
That was just a poor example how it could be used. Anyway,
you had to clutter the code to suppress the warning, too.
Sometimes there's no way of "fixing" warnings for all compilers,
you do it for one, and some other issue arises for another.

Consider this (semi-real-life example):
off_t off;
size_t siz;

if (siz > off) ;
may cause:
warning: signed/unsigned in comparison
on one implementation, whereas
if (siz > (size_t)off) ;
on another may issue:
warning: possible loss of data in cast
(besides that casting always makes me feel uneasy).
It's not obvious which side to cast to which.

(I actually solved it this way (through a macro):
if(siz + (off_t)0 > off + (size_t)0) ;
(clue: usual arithmetic conversions).
)
Finally, and it's been said before: The goal of turning
of ALL warnings from ALL compilers is ultimately futile,
because compilers are allowed to complain about anything
they feel like. "Warning: Source was modified at 2:37 AM;
sleep-deprived programmer may have made more mistakes than
usaul."

Well, yes, but my goal is not to turn off ALL warnings, but
only *known* and *inspected* warnings. The idea is that
I don't waste my work when line numbers change.

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Anonymous 7843]

In article <3r************@individual.net>,
S.Tobias <si***@FamOuS.BedBuG.pAlS.INVALID> wrote:

This idea has been wandering around me for some time, too.
It could work like this: programmer puts #pramas in the code,
which contain verbatim quotes (or regexes, or identifires) of warnings
that are to be suppressed for the next line. The utility program (or
a script) calculates line numbers and produces a list of warnings
(with the line numbers) to cut out from the compiler output.
Like this:
#pragma nowarn t.c:%n: warning: comparison between signed and unsigned
if (u>s)

Lately, I've been fixing this with:

if (s < 0 || u > (unsigned) s)

but only after careful examination of what s really
represents. If s just contained a sloppy assignment from
what was previously an unsigned value, then no need for the
extra mathematical rigor.

Also, a lot these warnings arise from people using int when
they should have used size_t.