best way to suppress "unused" warning?

[Rex Mottram]

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

[Richard Heathfield]

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

[Antoninus Twink]

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.

[Joachim Schmitz]

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

[Richard Tobin]

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

[fred.l.kleinschmidt]

On Apr 24, 6:05*pm, Rex Mottram <[e-mail]:

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

[CBFalconer]

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

[David Tiktin]

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

[Peter Nilsson]

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

[Richard Heathfield]

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

[Joachim Schmitz]

"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

[Joachim Schmitz]

"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

[Ian Collins]

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.

[Himanshu Chauhan]

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