Ignoring the return value of a function

[Mark Hobley]

I have a function with a prototype as follows:

int foobar(int n)

If I am not interested in the return value of the function, is it legal to
use the function in statement context as follows?

foobar(6); /* Is this legal? */

Or, is it necessary to create a dummy variable for the return value, and
disregard it, as follows?

int tmp;
tmp = foobar(6); /* variable tmp is not used anywhere else in the code */

Mark.

 

[Ben Pfaff]

I have a function with a prototype as follows:

int foobar(int n)

If I am not interested in the return value of the function, is it legal to
use the function in statement context as follows?

foobar(6); /* Is this legal? */

Yes.

 

[Andrew Poelstra]

Yes.

If you use lint, it might complain about it (since the
int return value is there for a reason, therefore you
should use it, goes the theory).

If you know the return value is irrelevant, you can do

(void) foobar(6);

if it makes you feel better.

 

[Paul N]

I have a function with a prototype as follows:

int foobar(int n)

If I am not interested in the return value of the function, is it legal to
use the function in statement context as follows?

foobar(6);          /* Is this legal? */

Yes, and you have probably already done so without realising. printf
returns an integer, which is nearly always ignored.

 

[Ersek, Laszlo]

printf returns an integer, which is nearly always ignored.

An unacceptable practice, in my opinion. I can think of two excuses:

- You are calling multiple output operations on the same stdio stream in a
row, and you finish off that sequence with a call to ferror() or a checked
fflush(). (In the ferror() case with appropriately line-buffered or
unbuffered streams, no actual output need to have happened due to the
stream operations, so ferror() may not have a chance to signal any error,
but that is no problem, if the technique is used consistently, *and* there
is a final checked fflush() or fclose() on the stream.)

- You are writing an error message to stderr on your way to exit with a
non-zero exit status.

Sometimes, if logging doesn't work, nothing should work. (The expression
"logging works" can be defined with different guarantees.) Sometimes,
looking at an incomplete log file on a full disk, it is better to know
that nothing happened than not to know what happened.

Cheers,
lacos

 

[Richard Bos]

If you use lint, it might complain about it (since the
int return value is there for a reason, therefore you
should use it, goes the theory).

If you know the return value is irrelevant, you can do

(void) foobar(6);

if it makes you feel better.

But please don't, because it will make most people who read your code
feel worse. Instead, get a better lint - these days, your compiler
should come with one, possibly built-in.

Richard

 

[Nick]

But please don't, because it will make most people who read your code
feel worse. Instead, get a better lint - these days, your compiler
should come with one, possibly built-in.

There are times when I do this - when I have a function whose return
value I usually use, but sometimes don't.

For example, the "create new stack frame" function in my interpreter
returns a pointer. This pointer can be used as a parameter to an "exit
from nested frames" to return early from a function (inside a loop,
(which creates its own frame) for example). Right at the start of
running a program I call the function to create a stack frame for the
entire program. I don't use that (early termination works entirely
differently) at all, so discard it with a (void) to mark that I know
there is a return value, and I know I don't want it.