Table of "safe" methods to suppress "unused parameter" warnings?

[Kaz Kylheku]

Doesn't look like omission of a name to me.


That's not asserting that non-use can be ignored at the
point declaration of the variable either. Both of the
things you've been positive about are not being demonstrated
here.

That is the spot where declarations go in that language: a special
(declare ...) expression which is the first thing that is enclosed
in the binding construct. (Though possibly preceded by a docstring,
in the case of a function or method definition.)

It's vaguely analogous to old style C:

int func(x, y)
int x;
int y;
{
}

The "int y" is the point of declaration of the variable, together
with the enclosure of y in the (x, y) list.

It gets complex because of type semantics though. In a family of

Given that, already:

void foo(const int);
void foo(int);

are exactly the same function type, in spite of const being a
real type qualifier, I don't see a problem.

function pointers, what if some of the parameters are ignored for
some of the functions - are they the same type?

Of course they are the same type; this has nothing to do with type.

Not every attribute which is syntactically a qualifier has to actually
be a semantic type qualifier.

It could be, syntactically, a storage class keyword also, since declarations
like "ignorable int * ignorable p" do not make sense.

Again, your view of "need" isn't shared universally.

Omitting the name works well in C++, which has a large community of users.

share it with the compiler, but sometimes redundancy is good
for humans to aid understanding.

What C++ giveth, C++ taketh away: the complete definition of a hello world
class with a non-inlined constructor and destructor requires the class name to
be written a whopping seven times.

 

[Tim Rentsch]

/* Oops! */
int foo(register int a) { (void) &a;return a; }

main() { printf("foo(10) = %d\n",foo(10)); }

Not Oops but Thank you. These days it's silly to use 'register'
at all, but even sillier to use it for a variable that is marked
UNUSED. So getting a complaint about it is a positive, not a
negative.

 

[Phil Carmody]

Not Oops but Thank you. These days it's silly to use 'register'
at all, but even sillier to use it for a variable that is marked
UNUSED.

I don't the the unused or otherwise nature of the parameter to be
in any way connected to whether it was passed in via a register or
not, so cannot support your "even sillier".

But in the context of function pointers, where calling conventions
are immutable, and as long as your compiler is intelligent enough
to honour your demands, if a function doesn't want to use a
parameter passed in, then that's only its business. You seem to
have a no-functions-are-ever-called-via-function-pointers mindset.

Phil

 

[Ike Naar]

I don't the the unused or otherwise nature of the parameter to be
in any way connected to whether it was passed in via a register or
not, so cannot support your "even sillier".

Parse error.

 

[Martin Shobe]

I don't the the unused or otherwise nature of the parameter to be
in any way connected to whether it was passed in via a register or
not, so cannot support your "even sillier".

I'll agree that using "register" for an unused parameter is no sillier
than using "register" on a used parameter. What I find silly is trying
to mark a parameter that is used (see the return statement) as unused.

[snip]

Martin Shobe

 

[Siri Crews]

Sometimes the same parameter list must be passed to a lot of different
functions, and some of those will not use all of the parameters,
resulting in some compilers emitting "unused parameter" warnings. Here
are all of the methods I have found so far for suppressing these:

Have you ever considerred you're fighing a fight that doesn't need to be fought.
First of all there's no reason to list all possible warnings one particular
compiler project dreamed up as as questionable usage. Nor do you have accept
their opinions about what is questionable usage.

A function's parameter list is what is called an interface. The function body is
what is called the implementation. Recently (in maybe the 1960s or the 1970s) it
was realised the interface can be disconnected from the implementation. You
could even have a library of implementations changing day by day, but as long as
the interfaces remained the same, library clients would be unaffected by changes
in the implementations. One recent innovation was too essentially link libraries
as a program runs so that library implementations could change run by run
without a program's awareness.

One consequence is to generalise interface. An interface might include
parameters that were once needed by an old implementation or are speculated to
be necessary to a future implementation. Because interfaces and implementations
could be decoupled, an interface with more information than one implementation
could support alternate implementation that do need that information. The
interface client really doesn't have to worry about implementation details.


Turn off the bloody unused parameters warning and start worrying about real
problems instead of invented trivialities.

 

[Phil Carmody]

Parse error.

s/the/see/

 

[Tim Rentsch]

I don't the the unused or otherwise nature of the parameter to be
in any way connected to whether it was passed in via a register or
not, so cannot support your "even sillier".

Do we have a miscommunication? I'm not talking about whether
an argument is passed in a register but only whether the 'register'
keyword is used. The latter has no bearing on the former. (Fine
point: in principle it could, under particular circumstances of
optimization, but it general it does not, notably when the call
and the definition are in different TU's and separately compiled.)

But in the context of function pointers, where calling conventions
are immutable, and as long as your compiler is intelligent enough
to honour your demands, if a function doesn't want to use a
parameter passed in, then that's only its business. You seem to
have a no-functions-are-ever-called-via-function-pointers mindset.

Are you laboring under a misconception? The presence or absence of
'register' in a parameter declaration has no effect on the
function's type (or pointer-to-function's type), type compatibility,
or the definedness of calling through a pointer-to-function. It is
perfectly legal to use a pointer-to-function type, either with or
without a 'register' attached to a given parameter, and use it to
call functions that do use 'register' in their prototypes and also
functions that do not use 'register' in their prototypes. Likewise
there is nothing wrong with declaring a function without 'register'
and defining it with 'register', or vice versa. There is no effect
on the calling semantics, whether the function is called directly
or through a pointer-to-function. (In fact all function calls occur
through a pointer-to-function, because of the rules for automatic
conversion of function types.)