Ethereal-dev: Re: [Ethereal-dev] Unused function parameters: Request for help

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Sun, 31 Mar 2002 17:51:44 -0800
On Sat, Mar 30, 2002 at 04:33:44PM +0100, Joerg Mayer wrote:
> If everyone could take a look at their pet dissectors

...or other code that they work with, e.g. GUI code...

> and add a _U_ to those
> unused parameters that can't be avoided and remove the others,

*OR* use the parameters, if that's the appropriate fix!  See below.

> this would
> help me a lot. I will start removing the remaining warnings after a 0.9.4
> release, but that will a) take time and b) may be against what the maintainer
> had in mind for this code.

I've checked in some of your changes to remove unused arguments or flag
them as _U_ - and checked in some additional changes as well, one of
which involved using the formerly-unused parameter.

I.e., the check revealed a bug - the "redraw_hex_dump()" wasn't using
the first argument passed to it, which was a pointer to the notebook
widget for which the hex dump whould be redrawn; it was, instead, using
a global variable, so it always redrew the main window's hex dump pane.

This meant that if you changed the font from the "User Interface" item
in the "Preferences" dialog box, the font of the main window's hex dump
pane would change, but the fonts in the hex dump panes of any "show
packet in new window" windows would *not* change.

I.e., one shouldn't blindly either remove unused arguments or flag them
with _U_; one should first ascertain whether the argument *should*, in
fact, be used.

Note also that, even though callbacks in GTK+ do not have fixed argument
lists determinable at compile time, they still do require specific
argument lists, so don't just remove unused arguments without checking
the GTK+ callback in question.  Bear in mind that the calling sequence
may depend on the *type* of callback....

> Main programs, tools and libs:

	...

>       4	grammar.c

	...

That's a generated file; unfortunately, Lemon doesn't make it easy to
put _U_ (or any other string) into the declaration or definition of the
function in question.