469,926 Members | 1,514 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,926 developers. It's quick & easy.

best way to suppress "unused" warning?

I'm using an API which does a lot of callbacks. In classic callback
style, each routine provides a void * pointer to carry user-defined
data. Sometimes, however, the user-defined pointer is not needed which
causes the compiler to spit out a "helpful" warning. For example:

% cat unused.c
#include <stdio.h>
int
foo(char *str, void *data)
{
puts(str);
return 0;
}

% gcc -c -W -Wall unused.c
unused.c:4: warning: unused parameter 'data'

I'm looking for an appropriate (safe, reasonably self-documenting) way
of suppressing that warning in cases where I expect it (thus I'm not
looking for the compiler flags to suppress the warning - I just want to
be able to mark the places I know about). I've used constructs like

data = data;
data++;
if (data != data) return;

And they all work but are a little too obfuscated for my taste. I'm sure
many other people have run into this - is there a recommended technique?

RM
Jun 27 '08 #1
13 9228
Rex Mottram said:
I'm using an API which does a lot of callbacks. In classic callback
style, each routine provides a void * pointer to carry user-defined
data. Sometimes, however, the user-defined pointer is not needed which
causes the compiler to spit out a "helpful" warning. For example:

% cat unused.c
#include <stdio.h>
int
foo(char *str, void *data)
{
puts(str);
return 0;
}

% gcc -c -W -Wall unused.c
unused.c:4: warning: unused parameter 'data'

I'm looking for an appropriate (safe, reasonably self-documenting) way
of suppressing that warning in cases where I expect it (thus I'm not
looking for the compiler flags to suppress the warning - I just want to
be able to mark the places I know about). I've used constructs like

data = data;
data++;
if (data != data) return;

And they all work but are a little too obfuscated for my taste. I'm sure
many other people have run into this - is there a recommended technique?
Lots of people use (void)data for this, and it's just as good a way as any
of those you mention, although I'd hesitate before claiming it's
"recommended" because such a claim leaves some important questions
unanswered (for instance, "recommended by whom?").

You might want to consider:

#define DISCARD_PARAMETER (void)

Usage:

DISCARD_PARAMETER data;

or you might prefer:

#define DISCARD_PARAMETER(p) (void)p

Usage:

DISCARD_PARAMETER(data);

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #2
On 25 Apr 2008 at 1:24, Richard Heathfield wrote:
Lots of people use (void)data for this, and it's just as good a way as
any of those you mention
Obfuscating your code to pacify your compiler or lint smacks to me of
letting the tail wag the dog.

Jun 27 '08 #3
Antoninus Twink wrote:
On 25 Apr 2008 at 1:24, Richard Heathfield wrote:
>Lots of people use (void)data for this, and it's just as good a way
as any of those you mention

Obfuscating your code to pacify your compiler or lint smacks to me of
letting the tail wag the dog.
In real life there may be coding standards that demand for this.

At one company I used to work for it was mandatory to use "-Wall -Werror",
or something eqivalent and all new code and on all older code once it got
touched.

It was a pain in the proverbian, but lead to much better code and lots of
yet unexplained faults mysteriously disappaered...

Bye, Jojo
Jun 27 '08 #4
In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>Lots of people use (void)data for this, and it's just as good a way as
any of those you mention
>Obfuscating your code to pacify your compiler or lint smacks to me of
letting the tail wag the dog.
It's a difficult balance to strike. I have at least once missed an
important warning because it was surrounded by unimportant ones that
I was expecting.

-- Richard

--
:wq
Jun 27 '08 #5
On Apr 24, 6:05*pm, Rex Mottram <r...@not.herewrote:
I'm using an API which does a lot of callbacks. In classic callback
style, each routine provides a void * pointer to carry user-defined
data. Sometimes, however, the user-defined pointer is not needed which
causes the compiler to spit out a "helpful" warning. For example:

% cat unused.c
#include <stdio.h>
int
foo(char *str, void *data)
{
* * *puts(str);
* * *return 0;

}

% gcc -c -W -Wall unused.c
unused.c:4: warning: unused parameter 'data'

I'm looking for an appropriate (safe, reasonably self-documenting) way
of suppressing that warning in cases where I expect it (thus I'm not
looking for the compiler flags to suppress the warning - I just want to
be able to mark the places I know about). I've used constructs like

* * * * data = data;
* * * * data++;
* * * * if (data != data) return;

And they all work but are a little too obfuscated for my taste. I'm sure
many other people have run into this - is there a recommended technique?
This is non-standard, but many compilers will not issue such
a warning when the comment /* ARGSUSED *? immediately
precedes the function:

/* ARGSUSED */
foo(char *str, void *data)
{
...
}

--
Fred Kleinschmidt

Jun 27 '08 #6
Richard Tobin wrote:
Antoninus Twink <no****@nospam.invalidwrote:
.... snip ...
>
>Obfuscating your code to pacify your compiler or lint smacks to
me of letting the tail wag the dog.

It's a difficult balance to strike. I have at least once missed
an important warning because it was surrounded by unimportant
ones that I was expecting.
Which, to me, points out the importance of handling those
'unimportant' warnings. I think there are very few which cannot be
eliminated by minor rewriting.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
Jun 27 '08 #7
On 24 Apr 2008, Rex Mottram <re**@not.herewrote:
I'm using an API which does a lot of callbacks. In classic
callback style, each routine provides a void * pointer to carry
user-defined data. Sometimes, however, the user-defined pointer is
not needed which causes the compiler to spit out a "helpful"
warning. For example:

% cat unused.c
#include <stdio.h>
int
foo(char *str, void *data)
foo(char *str, void *unused)
{
puts(str);
return 0;
}

% gcc -c -W -Wall unused.c
unused.c:4: warning: unused parameter 'data'
unused.c:4: warning: unused parameter 'unused'

OK, it doesn't *suppress* the warning. But it does make it
*reasonably* self-documenting ;-)

Dave

--
D.a.v.i.d T.i.k.t.i.n
t.i.k.t.i.n [at] a.d.v.a.n.c.e.d.r.e.l.a.y [dot] c.o.m
Jun 27 '08 #8
Joachim Schmitz wrote:
Antoninus Twink wrote:
Richard Heathfield wrote:
Lots of people use (void)data for this, and it's just as good
a way as any of those you mention
Obfuscating your code to pacify your compiler or lint smacks
to me of letting the tail wag the dog.

In real life there may be coding standards that demand for this.
Of course, tail wagging the dog is standard policy in many
avenues of life. That doesn't mean it's sensible.
At one company I used to work for it was mandatory to use
"-Wall -Werror", or something eqivalent and all new code and
on all older code once it got touched.
So if the compiler ever get's upgraded, you may have to 'correct'
thousands of lines of perfectly correct code because the compiler
writers decided to add another warning? Brilliant.

Did you have to rewrite third party library sources as well?
It was a pain in the proverbian, but lead to much better code
Warning free is not a measure of 'better'. But I'm in a minority
on that.
and lots of yet unexplained faults mysteriously disappaered...
I'm sure it also lead to the appearance (albeit rare) of
mysterious faults that went undiscovered for some time until a
critical moment precisely because all the programmers have
been conditioned to write code that eludes diagnostics and
static analysis.

Ever heard the term superbugs. ;-)

--
Peter
Jun 27 '08 #9
Peter Nilsson said:

<snip>
Warning free is not a measure of 'better'. But I'm in a minority
on that.
But not a minority of one. I happen to agree with you on this.
Nevertheless, *to a first approximation*, a low warning count is better
than a high warning count. If code generates a vast number of warnings,
that is typically not a good sign, although there might be a good reason
for it. (Think pulse rate - 160 heartbeats a minute is not generally
considered healthy, but if the measuree has just completed a run of 10,000
metres it probably counts as pretty low!)

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jun 27 '08 #10
"Peter Nilsson" <ai***@acay.com.auschrieb im Newsbeitrag
news:bb**********************************@l28g2000 prd.googlegroups.com...
Joachim Schmitz wrote:
>Antoninus Twink wrote:
Richard Heathfield wrote:
Lots of people use (void)data for this, and it's just as good
a way as any of those you mention

Obfuscating your code to pacify your compiler or lint smacks
to me of letting the tail wag the dog.

In real life there may be coding standards that demand for this.

Of course, tail wagging the dog is standard policy in many
avenues of life. That doesn't mean it's sensible.
>At one company I used to work for it was mandatory to use
"-Wall -Werror", or something eqivalent and all new code and
on all older code once it got touched.

So if the compiler ever get's upgraded, you may have to 'correct'
thousands of lines of perfectly correct code because the compiler
writers decided to add another warning? Brilliant.
The vast majority was stuff like comment inside comment, steming from the
function headers like this:

/***********
/*
/* some text describing the function
*/

Once they've been fixed, the real warnings became visible.
Statement with no effect (e.g. from ; after while())
conversion of <typeto <typewithout a case (and no the fix was not to add
the cast)
implicit declaration of <function>
unused variable

etc.

Newer compiler versions didn't create many new warnings, so that wasn't much
of an issue,
but porting to a different platform (and compiler) then produced a new and
extensive set of warnings, the majority usefull and correct ones.
Did you have to rewrite third party library sources as well?
There were none, fortunatly.
>It was a pain in the proverbian, but lead to much better code

Warning free is not a measure of 'better'. But I'm in a minority
on that.
>and lots of yet unexplained faults mysteriously disappaered...
One example was lots of warnigs about unused variables. We removed these and
the code didn't crash anymore. Later we learned that that particular
compiler's optimizer had a problem with unused vairables, resulting in bad
code.
OK, in this case a compiler upgrade would have fixed it too, but at that
time we a) didn't know and b) the fixed compiler wasn't available.
I'm sure it also lead to the appearance (albeit rare) of
mysterious faults that went undiscovered for some time until a
critical moment precisely because all the programmers have
been conditioned to write code that eludes diagnostics and
static analysis.
I'm not aware of any

Bye, Jojo
Jun 27 '08 #11

"Peter Nilsson" <ai***@acay.com.auschrieb im Newsbeitrag
news:bb**********************************@l28g2000 prd.googlegroups.com...
Joachim Schmitz wrote:
<snip>
>(removing the warnings) was a pain in the proverbian, but lead to much
better code

Warning free is not a measure of 'better'. But I'm in a minority
on that.
It was not (only) better because of the lack of warnings, but (mainly) due
to the numbers of bugs we spotted and removed in the due course of
investigating and eliminating the warnings.

Bye, Jojo
Jun 27 '08 #12
Joachim Schmitz wrote:
Antoninus Twink wrote:
>On 25 Apr 2008 at 1:24, Richard Heathfield wrote:
>>Lots of people use (void)data for this, and it's just as good a way
as any of those you mention
Obfuscating your code to pacify your compiler or lint smacks to me of
letting the tail wag the dog.
In real life there may be coding standards that demand for this.
Adding unnamed parameters would fix this case and break nothing. But I
guess there little chance of such a simple change making its way into
the standard.

--
Ian Collins.
Jun 27 '08 #13
Rex Mottram wrote:
I'm using an API which does a lot of callbacks. In classic callback
style, each routine provides a void * pointer to carry user-defined
data. Sometimes, however, the user-defined pointer is not needed which
causes the compiler to spit out a "helpful" warning. For example:

% cat unused.c
#include <stdio.h>
int
foo(char *str, void *data)
{
puts(str);
return 0;
}

% gcc -c -W -Wall unused.c
unused.c:4: warning: unused parameter 'data'

I'm looking for an appropriate (safe, reasonably self-documenting) way
of suppressing that warning in cases where I expect it (thus I'm not
looking for the compiler flags to suppress the warning - I just want to
be able to mark the places I know about). I've used constructs like

data = data;
data++;
if (data != data) return;

And they all work but are a little too obfuscated for my taste. I'm sure
many other people have run into this - is there a recommended technique?

RM
Hi,

With GCC you can use __attribute__((unused))

Regards
--Himanshu
Jun 27 '08 #14

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by Daniele Benegiamo | last post: by
6 posts views Thread by Chris Stankevitz | last post: by
reply views Thread by Steve B. | last post: by
20 posts views Thread by Andreas Griesmayer | last post: by
11 posts views Thread by Charles Sullivan | last post: by
11 posts views Thread by arnuld | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.