Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

kainjow

Moderator emeritus
Original poster
Jun 15, 2000
7,958
7
Is there any good reason why a C function or Objective-C method that has a non-void return value should be cast to void when the return value is unused? I see this all the time in a certain project.

For example:

Code:
extern int myFunc();

...

(void)myFunc();

// vs

myFunc();

I just compared the assembly for a tiny test project and it appears identical, so I suppose it's something leftover from an older time when it did make a difference?
 
I suspect it's to do with what the compiler will do if you don't specify void. From here (which seems targeted at C++ but I think is true for C too):

"Functions, for which no return type is explicitly declared, implicitly receive int as the return type. This can be confusing for a beginner, since the compiler gives a warning for a missing return type. Because of this, functions which return no value should specify void as the return type. "
 
I just compared the assembly for a tiny test project and it appears identical, so I suppose it's something leftover from an older time when it did make a difference?

It makes a difference to the reader of the code:

myFunc ();

means: I called the function and forgot to check what value it returns.

(void) myFunc ();

means: I called the function, I know that it returns a value, and I also know that I don't care which value it returns.
 
What I read recently is that C typically puts the return value in a register, I believe they use GPR1 on PPC and probably eax on x86. "void" would simply let the compiler know that the caller cannot rely on a defined value in the return register. If a return value is bigger than a register and not a pointer (e.g., NSRect), I would expect there would be space reserved on the stack to which the return register would point.

Most likely the original C compilers wanted to have this parameter for consistency, so that the compiler could be more easily written. As I recall, it is like the difference between "Procedure" and "Function" in Pascal, though I think Pascal handles the return value differently. In Objective-C, if you write a method without a cast, it expects you to return something - either an int or a pointer but not a float or oversized object like an NSRect. I am not exactly sure why it works that way.
 
As stated, it's supposed to help future readers know that the original writer knows the function is returning a value and is ignoring it on purpose. It's a technique that I don't like and don't use unless the company I'm working for says so in their coding style guidelines. I don't see much value in doing it considering that it doesn't tell you why the person is ignoring the return value. If I have a good reason to ignore a return value, I'll write a comment about it. Otherwise, I take a lack of checking (and (void) cast) to mean "I don't care about the return value". Plus, from my experience at least, it's not a widely used technique and if everyone isn't doing it consistently, it really adds little value... it's just more stuff to read.

I only use casts when really necessary.
 
Could it be simply to mitigate compiler warnings?

I don't know about other compilers, but as far as GCC goes it won't normally give you a warning if you don't use a function's return value. Even using the "-Wall" option won't give a warning on that. To my knowledge, the only way to get the compiler to warn you about this would be to use the warn-unused-result function attribute. Let's say you did use the function attribute so the compiler did warn when you didn't use the return value. Using the void cast, like in this thread, won't eliminate the warning. To be honest, I'm not sure if there is a way to eliminate the warning without actually using the return value or compiling that file with a certain -W gcc option.

Really, it's just to let other developers know that the author chose not to use the return value. Now, I have heard of some old static analysis tools that use this void cast to eliminate warnings about unused return values, but I doubt that is why people do this today.
 
I don't know of any compiler which will warn about ignoring return values, but some automated code checking tools do. In many cases, the return value is actually an error code, so those code checkers will point out you're assuming happy flow. Of course, putting a (void) in front of those functions will silence the tool without actually improving the code...
 
It makes a difference to the reader of the code:

myFunc ();

means: I called the function and forgot to check what value it returns.

(void) myFunc ();

means: I called the function, I know that it returns a value, and I also know that I don't care which value it returns.

This makes the most sense. However, it just seems like extra clutter to me.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.