What are the consequences of ignoring: warning: unused parameter

Question

I am working on a C++ project and I noticed that we have a number of warnings about unused parameters.

What effect could it have if these warnings are ignored?

Answer 1

The function with an unused parameter may have a real bug in the following cases:

1. There is an output parameter, which is not being assigned or written into, resulting in undefined value for the caller.

2. One of parameters is a callback function pointer, which you must invoke and forget to do so. May happen if there is a lot of #ifdefs in the function.

3. You declare a local variable with the same name that shadows a parameter and subsequently use the wrong value down in the function.

Not using an input parameters may be harmless, but you can reduce the noise to see useful warnings by marking unused input parameters explicitly in the beginning of the function by casting it to void (works for both C and C++):

(void)param1;

Or,

#define UNUSED(expr) do { (void)(expr); } while (0)
...

void foo(int param1, int param2)
{
    UNUSED(param2);
    bar(param1);
}

Or omit parameter name (C++ only):

void foo(int param1, int /*param2*/)
{
    bar(param1);
}

Answer 2

If you have a whole lot of unimportant warnings that are not important to you, you may overlook the important warning about the line of code that you just wrote that is hiding in the middle of them.

Answer 3

For a gcc specific way to disable the warning, you can use __attribute__((unused)) like

void foo(int a, int b __attribute__((unused))) {

}

To ignore the second parameter. If your program relies on GCC technologies already, you can use that attribute to be 100% safe from that kind of warning.

Answer 4

It means you wrote a function that takes a parameter but doesn't use the parameter. It's harmless but it might indicate bugs in some cases.

Generally you can silence this warning by removing the parameter name, leaving it anonymous, but that may not be desirable depending on why the parameter is not being used.

I'd suggest you turn off the warning if it is making it harder to find the real problems.

Answer 5

In C++ you can have default arguments:

int sum(int first, int second=0){   // should not give warning
    return first+first;
}

You can also have extra argument:

int sum(int first, int second){     // should give warning
    first *= 2;
    return first;
}

If you have a parameter you're not using and it's not defaulted, you should get a warning because you're asking the program to pass extra values to the stack that are never referenced, and therefore is doing more work than it should.

Maybe it means you forgot part of the function logic, too.

Answer 6

None. except [EDIT]: as others have pointed out, You could have an unassigned output parameter.

You should clean them up, because on many occasions I have seen developers ignore important warnings that were 'hidden' in amongst a large number of warnings, and they were so used to seeing warnings they never paid any attention to them. I try to have zero warnings at all times, and set compiler warnings to the maximum level.

Answer 7

That depends of if you intended to use the paramater. E.g.

const int Size = 12; // intended for use in some other function

char* MakeBuffer(int size)
{
   return new char[Size];
}

In this code 'size' is unused, and instead the constant 'Size' is being used. So the warning will highlight problems of this type for you.

However, if you never indented to use the parameter then it should just be removed from the method signature. Unless you need to match a signature for a virtual method, or function pointer, if that's the case then you don't have the option to remove it.

Answer 8

If a method doesn't use a parameter then the first question that arises is that why is that parameter a part of the method's signature in the first place. These warnings do make sense since it is bad design that these are referring to and further, there is a little overhead as well that whenever this method is called, this parameter is pushed on the stack so, the best is to refactor the method and remove such parameters which do not have any use.

Having said that, leaving these parameters doesnt harm a lot except for a little overhead that I mentioned.