Suppressing "Parameter not used" Warning

Started by Dave Hansen October 3, 2005
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.