[Slightly OT] Casting non-void function results to void in modern compilers.

[David M. Wilson]

I know this doesn't specifically pertain to the scope of comp.lang.c,
but I don't know of a better forum to post it on, besides, what is the
practicality of comp.lang.c if it weren't for answers to questions
such as this?

I see an awful lot of code on a day to day basis like so:

(void) printf(...);


I was told in my fledgeling years that this was used as a hint to the
compiler to tell it not to save the return value of the called
function, because it isn't used. I always wondered about that,
considering the statement is not an assignment expression, and the
return value 'flows off the end of the expression' anyway.

Is this a useful modern optimisation? I would have thought not, but I
still see it in modern code. Surely a modern (or even ancient)
compiler can see that the result of printf() is not used, and so it
should perform any possible optimisations based on the fact the return
value isn't used.

Am I wrong? Thanks,


David.

 

[Ed Morton]

I know this doesn't specifically pertain to the scope of comp.lang.c,
but I don't know of a better forum to post it on, besides, what is the
practicality of comp.lang.c if it weren't for answers to questions
such as this?

I see an awful lot of code on a day to day basis like so:

(void) printf(...);


I was told in my fledgeling years that this was used as a hint to the
compiler to tell it not to save the return value of the called
function, because it isn't used. I always wondered about that,
considering the statement is not an assignment expression, and the
return value 'flows off the end of the expression' anyway.

Is this a useful modern optimisation? I would have thought not, but I
still see it in modern code. Surely a modern (or even ancient)
compiler can see that the result of printf() is not used, and so it
should perform any possible optimisations based on the fact the return
value isn't used.

Am I wrong? Thanks,

The compiler can see that the return code isn't used, but it can't tell
whether or not it SHOULD have been used. By the author specifying the
"void" cast, they're telling the compiler (or lint) not to issue a
warning for that line as the return code is, in this case, being
intentionally discarded.

Ed.

 

[Kevin Goodsell]

I know this doesn't specifically pertain to the scope of comp.lang.c,
but I don't know of a better forum to post it on, besides, what is the
practicality of comp.lang.c if it weren't for answers to questions
such as this?

I see an awful lot of code on a day to day basis like so:

(void) printf(...);


I was told in my fledgeling years that this was used as a hint to the
compiler to tell it not to save the return value of the called
function, because it isn't used.

I don't believe it accomplishes anything like that. The compiler
probably can't do anything useful with the information that the return
value is unused - the code for printf() (which probably resides in some
library somewhere that the compiler doesn't know or care about) is
already returning a value. printf isn't going to be re-written to omit
the return just because you cast it to void.

To the best of my knowledge, the cast-to-void technique is used solely
to silence warnings from static code checking tools like LINT, or from
over-zealous compilers.

I always wondered about that,
considering the statement is not an assignment expression, and the
return value 'flows off the end of the expression' anyway.

Is this a useful modern optimisation?

I don't believe it is, or has ever been, an optimization, useful or
otherwise.

-Kevin

 

[CBFalconer]

.... snip ...

I see an awful lot of code on a day to day basis like so:

(void) printf(...);

I was told in my fledgeling years that this was used as a hint to
the compiler to tell it not to save the return value of the called
function, because it isn't used. I always wondered about that,
considering the statement is not an assignment expression, and the
return value 'flows off the end of the expression' anyway.

Opinions vary, but one attitude is that:

a) This avoids generating 'result discarded' messages in lint.
b) This indicates to any future maintainer that there IS a
result being returned and discarded, which he may use if the
occasion arises.

Another attitude is that it is meaningless clutter.

 

[Arthur J. O'Dwyer]

I know this doesn't specifically pertain to the scope of comp.lang.c,
but I don't know of a better forum to post it on, besides, what is the
practicality of comp.lang.c if it weren't for answers to questions
such as this?

I see an awful lot of code on a day to day basis like so:

(void) printf(...);

Hee hee!

Message-ID: <[email protected]>

Ben.c:17:7: Return value (type int) ignored: putchar(p)
Result returned by function call is not used.

Gosh. Lint really _is_ prehistoric, isn't it?

According to K&R2, putchar() does indeed return an int. I suspect
a cast to void would silence lint, but it's hardly worth it, is it?

Some old code, and some overly-portable code, does use casts to
void. We even get questions about (void)printf here occasionally.

</quote>

-Arthur

 

[Christian Bau]

I know this doesn't specifically pertain to the scope of comp.lang.c,
but I don't know of a better forum to post it on, besides, what is the
practicality of comp.lang.c if it weren't for answers to questions
such as this?

I see an awful lot of code on a day to day basis like so:

(void) printf(...);


I was told in my fledgeling years that this was used as a hint to the
compiler to tell it not to save the return value of the called
function, because it isn't used. I always wondered about that,
considering the statement is not an assignment expression, and the
return value 'flows off the end of the expression' anyway.

Is this a useful modern optimisation? I would have thought not, but I
still see it in modern code. Surely a modern (or even ancient)
compiler can see that the result of printf() is not used, and so it
should perform any possible optimisations based on the fact the return
value isn't used.

If a function returns a value, and the caller doesn't use that return
value, then there are two possibilities:

1. The caller made a mistake and should have used the value.
2. The caller knew what he/she was doing and had no need for the
value.

When you cast the return value to void, you explicitely tell the
compiler that yes, you know that the function returns a value, and no,
you don't want to use it. Without that cast, many compilers will give a
warning telling you that you might have missed something.

It is also a good hint to other programmers.

 

[Peter Nilsson]

I know this doesn't specifically pertain to the scope of comp.lang.c,
but I don't know of a better forum to post it on, besides, what is the
practicality of comp.lang.c if it weren't for answers to questions
such as this?

I see an awful lot of code on a day to day basis like so:

(void) printf(...);

Hee hee!

Message-ID: <[email protected]>

Ben.c:17:7: Return value (type int) ignored: putchar(p)
Result returned by function call is not used.

Gosh. Lint really _is_ prehistoric, isn't it?

According to K&R2, putchar() does indeed return an int. I suspect
a cast to void would silence lint, but it's hardly worth it, is it?

Some old code, and some overly-portable code, does use casts to
void.

To my knowledge, I've never read anything to suggest it was being done
for portability reasons. Is there any evidence of such?

I believe the standard inherited (and it remains in C99) the K&R C
behaviour of allowing functions which don't have an explicit return
statement to function as normal, so long as the calling function
didn't attempt to use a value from that function. So, C has always had
issues with ignored function return values.

I can understand why lint (et al) would give the warning, e.g...

sin(x);

But, I can't see that actual programming instances where the warning
might actually highlight an error would be terribly common.

I'm all ears (well eyes), if anyone has any anecdotes.

 

[Vijay Kumar R Zanvar]

[..]

I can understand why lint (et al) would give the warning, e.g...

What does "et al" mean?

 

[Ben Pfaff]

[..]

I can understand why lint (et al) would give the warning, e.g...

What does "et al" mean?

"and others"