Suppressing "Parameter not used" Warning

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

They do (or something similar).

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

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

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

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

[...]

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

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.

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

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

[...]

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.

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

[suppressed "parameter not used" warnings]

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

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

Same here.

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

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

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.

--

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

# 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

Raining down sulphur is like an endurance trial, man. Genocide is the most exhausting activity one can engage in. Next to soccer.

[snip]

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 siXtY@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

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

--
Eric.Sosman@sun.com

That's how great ideas die - someone says "ugh"... ;-)

:-)

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

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

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 siXtY@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

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.