(void) printf vs printf

[whatluo]

Hi, c.l.cs

I noticed that someone like add (void) before the printf call,
like: (void) printf("Timeout \n"); while the others does't. So
can someone tell me whether there any gains in adding
(void) to printf.

Thanks,

Whatluo.

[Walter Roberson]

Re: (void) printf vs printf

In article <1117085321.411 019.169790@g44g 2000cwa.googleg roups.com>,
whatluo <whatluo@gmail. com> wrote:[color=blue]
>I noticed that someone like add (void) before the printf call,
>like: (void) printf("Timeout \n"); while the others does't. So
>can someone tell me whether there any gains in adding
>(void) to printf.[/color]

It can silence a compiler (or stand-alone "lint" program) warning
that the result of a function has been thrown away.

Also, if the programmer is being particularily careful to check
error conditions at every place errors can occur, then
a (void) on the printf() can be a signal that the lack of error
checking on that one statement is a deliberate design decision
instead of something that was overlooked.
--
History is a pile of debris -- Laurie Anderson

[Christian Bau]

Re: (void) printf vs printf

In article <1117085321.411 019.169790@g44g 2000cwa.googleg roups.com>,
"whatluo" <whatluo@gmail. com> wrote:
[color=blue]
> Hi, c.l.cs
>
> I noticed that someone like add (void) before the printf call,
> like: (void) printf("Timeout \n"); while the others does't. So
> can someone tell me whether there any gains in adding
> (void) to printf.[/color]

printf returns a value.

When a function returns a value, and the programmer ignores the code, I
would want to know why. There are usually two explanations: The
programmer made a mistake ignoring the return value, or the programmer
did ignore the return value on purpose. When you write

printf (...);

I have no idea if you wanted to ignore the return value or not. If you
write

(void) printf (...);

it tells me that the programmer knew that printf returns a value, and
made a conscious decision to ignore that value. Do some professional
programming, try finding a few bugs in a million lines of other people's
code, and you will appreciate such things.

[SM Ryan]

Re: (void) printf vs printf

Christian Bau <christian.bau@ cbau.freeserve. co.uk> wrote:
# In article <1117085321.411 019.169790@g44g 2000cwa.googleg roups.com>,
# "whatluo" <whatluo@gmail. com> wrote:
#
# > Hi, c.l.cs
# >
# > I noticed that someone like add (void) before the printf call,
# > like: (void) printf("Timeout \n"); while the others does't. So
# > can someone tell me whether there any gains in adding
# > (void) to printf.
#
# printf returns a value.
#
# When a function returns a value, and the programmer ignores the code, I
# would want to know why. There are usually two explanations: The
# programmer made a mistake ignoring the return value, or the programmer
# did ignore the return value on purpose. When you write

I routinely notice lots of people checking the return of printf
instead of simply looking at the terminal window.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Leave it to the Catholics to destroy existence.

[Giorgos Keramidas]

Re: (void) printf vs printf

SM Ryan <wyrmwif@tang o-sierra-oscar-foxtrot-tango.fake.org> writes:[color=blue]
>Christian Bau <christian.bau@ cbau.freeserve. co.uk> wrote:
># In article <1117085321.411 019.169790@g44g 2000cwa.googleg roups.com>,
># "whatluo" <whatluo@gmail. com> wrote:
>#
># > Hi, c.l.cs
># >
># > I noticed that someone like add (void) before the printf call,
># > like: (void) printf("Timeout \n"); while the others does't. So
># > can someone tell me whether there any gains in adding
># > (void) to printf.
>#
># printf returns a value.
>#
># When a function returns a value, and the programmer ignores the code, I
># would want to know why. There are usually two explanations: The
># programmer made a mistake ignoring the return value, or the programmer
># did ignore the return value on purpose. When you write
>
> I routinely notice lots of people checking the return of printf
> instead of simply looking at the terminal window.[/color]

Of course, sometimes just staring at terminals may be deceptive at
times. Consider a program that prints whitespace separated words and
shows two words on your terminal:

hello world

Have these been printed by a single call to printf?

printf("hello world\n");

Two successive calls?

printf("hello ");
printf("world\n ");

Or maybe three calls, where the middle one failed, for some obscure
(and undetected by just staring at the output) reason?

printf("hello ");
printf("strange ");
printf("world\n ");

[Richard Bos]

Re: (void) printf vs printf

"whatluo" <whatluo@gmail. com> wrote:
[color=blue]
> I noticed that someone like add (void) before the printf call,
> like: (void) printf("Timeout \n"); while the others does't. So
> can someone tell me whether there any gains in adding
> (void) to printf.[/color]

Nothing. It shuts up geriatric versions of lint, that's all. But you're
better off using a lint that wasn't designed on clay tablets anyway.

Richard

[Richard Bos]

Re: (void) printf vs printf

"P.J. Plauger" <pjp@dinkumware .com> wrote:
[color=blue]
> Note, however, that these rules do *not* apply to casting
> the value returned by malloc. So, despite the fact(s) that
>
> -- a (void) cast is *never* needed in a conforming C program, and
>
> -- it's only real-world effect is to silence diagnostics in
> a non-standard dialect of C (lint)
>
> it is nevertheless a Good Thing (TM) to write (void) casts and
> a Bad Thing (SM) to do exactly the same thing for the return
> value of malloc.[/color]

No, because of those reasons, and more, it is a Bad Thing to write
(void) casts and also a Bad Thing to cast malloc().
[color=blue]
> Go figure.[/color]

Furrfu.

Richard

[Bhatnagar Achindra]

Re: (void) printf vs printf

int printf(...) and void printf(...)

When we use printf(...) and we don't handle the return values the
return value is destroyed with the loading and execution of the next
statement call.

When use void printf(...) we instruct the system to flush out any
return values before moving to the next statement, thus we clean up any
possibility of fetching the return value.

Positive values from the function call specifies the number of bytes
written to STDOUT, excluding '\0' in general, while a negative value
tells the error code if occured.

[No Such Luck]

Re: (void) printf vs printf

> Also, if the programmer is being particularily careful to check[color=blue]
> error conditions at every place errors can occur, then
> a (void) on the printf() can be a signal that the lack of error
> checking on that one statement is a deliberate design decision
> instead of something that was overlooked.[/color]

Interesting. I knew things like successful file openings should be
error checked, and pointers should be checked before accessing, etc.
But printfs? What is usually the accepted degree of error checking?

[Eric Sosman]

Re: (void) printf vs printf



No Such Luck wrote:[color=blue][color=green]
>>Also, if the programmer is being particularily careful to check
>>error conditions at every place errors can occur, then
>>a (void) on the printf() can be a signal that the lack of error
>>checking on that one statement is a deliberate design decision
>>instead of something that was overlooked.[/color]
>
>
> Interesting. I knew things like successful file openings should be
> error checked, and pointers should be checked before accessing, etc.
> But printfs? What is usually the accepted degree of error checking?[/color]

How important is the output? What are the consequences
if it fails to appear?

<whimsy>

A complete absence of error checking suggests that the
programmer places no value on the output and doesn't care
whether it appears or not. If so, the program's efficiency
can probably be improved by removing all the printf() calls,
along with the computations that produce data for them.
Following this principle, here is an optimized version of
the canonical "Hello, world!" program:

int main(void) {
return 0;
}

A great many programs can be optimized this way, and it
turns out that quite a few of them, after optimization,
become identical to the code shown above. This is a great
savings, because debugging and testing this one piece of
code essentially debugs and tests all those other programs
at the same time. A triumph for code re-use!

</whimsy>

--
Eric.Sosman@sun .com

[Jens.Toerring@physik.fu-berlin.de]

Re: (void) printf vs printf

Bhatnagar Achindra <achindra@gmail .com> wrote:[color=blue]
> int printf(...) and void printf(...)[/color]
[color=blue]
> When we use printf(...) and we don't handle the return values the
> return value is destroyed with the loading and execution of the next
> statement call.[/color]
[color=blue]
> When use void printf(...) we instruct the system to flush out any[/color]

I guess you meant "( void ) printf( .... )", didn't you?
[color=blue]
> return values before moving to the next statement, thus we clean up any
> possibility of fetching the return value.[/color]

No, cast to void or not doesn't "instruct the system" to do anything.
It only explicitely tells the compiler (or other programs or perhaps
other programmers that analyze the surce code) that the return value
of printf() will never get used. The compiler can find out about this
all by itself and will create identical code with and without the cast.
[color=blue]
> Positive values from the function call specifies the number of bytes
> written to STDOUT, excluding '\0' in general,[/color]

printf() never writes out a '\0', so it can't exclude it from the count.
Only function printing into strings like sprintf() would write out a
'\0' and for these function the final '\0' never gets included into the
count.
[color=blue]
> while a negative value tells the error code if occured.[/color]

A negative return value just indicates that there was an error,
it's not an error code in the sense that you could derive from
the value what went wrong.
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de

[CBFalconer]

Re: (void) printf vs printf

Jens.Toerring@p hysik.fu-berlin.de wrote:[color=blue]
> Bhatnagar Achindra <achindra@gmail .com> wrote:
>[/color]
.... snip ...[color=blue]
>[color=green]
>> Positive values from the function call specifies the number of
>> bytes written to STDOUT, excluding '\0' in general,[/color]
>
> printf() never writes out a '\0', so it can't exclude it from the
> count. Only function printing into strings like sprintf() would
> write out a '\0' and for these function the final '\0' never gets
> included into the count.[/color]

<nitpick> Counter example: (1 == printf("%c", '\0')); </nitpick>

--
Some informative links:
news:news.annou nce.newusers

http://www.geocities.com/nnqweb/

http://www.catb.org/~esr/faqs/smart-questions.html

http://www.caliburn.nl/topposting.html

http://www.netmeister.org/news/learn2quote.html

[Jens.Toerring@physik.fu-berlin.de]

Re: (void) printf vs printf

CBFalconer <cbfalconer@yah oo.com> wrote:[color=blue]
> Jens.Toerring@p hysik.fu-berlin.de wrote:[color=green]
>> Bhatnagar Achindra <achindra@gmail .com> wrote:
>>[/color]
> ... snip ...[color=green]
>>[color=darkred]
>>> Positive values from the function call specifies the number of
>>> bytes written to STDOUT, excluding '\0' in general,[/color]
>>
>> printf() never writes out a '\0', so it can't exclude it from the
>> count. Only function printing into strings like sprintf() would
>> write out a '\0' and for these function the final '\0' never gets
>> included into the count.[/color][/color]
[color=blue]
> <nitpick> Counter example: (1 == printf("%c", '\0')); </nitpick>[/color]

Right you are - I was only thinking about the one at the end of
a string written by sprintf() etc.

Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@p hysik.fu-berlin.de
\______________ ____________ http://www.toerring.de

[Keith Thompson]

Re: (void) printf vs printf

"No Such Luck" <no_suchluck@ho tmail.com> writes:[color=blue][color=green]
>> Also, if the programmer is being particularily careful to check
>> error conditions at every place errors can occur, then
>> a (void) on the printf() can be a signal that the lack of error
>> checking on that one statement is a deliberate design decision
>> instead of something that was overlooked.[/color]
>
> Interesting. I knew things like successful file openings should be
> error checked, and pointers should be checked before accessing, etc.
> But printfs? What is usually the accepted degree of error checking?[/color]

It's largely a question of how you'd handle the error. In the
simplest case, the classic "hello, world" program:

#include <stdio.h>
int main(void)
{
printf("Hello, world\n");
return 0;
}

you could do something like this:

#include <stdio.h>
int main(void)
{
int result = printf("Hello, world\n");
if (result < 0) {
/* handle the error? */
}
return 0;
}

A failure in printf() generally indicates that the program is unable
to produce output. What are you going to do, print an error message?

Conceivably you could print an error message to stderr (which *might*
not be having the same problems that stdout is having), or abort the
program with an error status, but most programmers don't bother most
of the time.

If C had a decent exception handling mechanism, and the standard
library routines used it, it would provide a good way to handle this
kind of error.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[SM Ryan]

Re: (void) printf vs printf

Giorgos Keramidas <keramida@ceid. upatras.gr> wrote:
# SM Ryan <wyrmwif@tang o-sierra-oscar-foxtrot-tango.fake.org> writes:
# >Christian Bau <christian.bau@ cbau.freeserve. co.uk> wrote:
# ># In article <1117085321.411 019.169790@g44g 2000cwa.googleg roups.com>,
# ># "whatluo" <whatluo@gmail. com> wrote:
# >#
# ># > Hi, c.l.cs
# ># >
# ># > I noticed that someone like add (void) before the printf call,
# ># > like: (void) printf("Timeout \n"); while the others does't. So
# ># > can someone tell me whether there any gains in adding
# ># > (void) to printf.
# >#
# ># printf returns a value.
# >#
# ># When a function returns a value, and the programmer ignores the code, I
# ># would want to know why. There are usually two explanations: The
# ># programmer made a mistake ignoring the return value, or the programmer
# ># did ignore the return value on purpose. When you write
# >
# > I routinely notice lots of people checking the return of printf
# > instead of simply looking at the terminal window.
#
# Of course, sometimes just staring at terminals may be deceptive at
# times. Consider a program that prints whitespace separated words and
# shows two words on your terminal:
#
# hello world
#
# Have these been printed by a single call to printf?
#
# printf("hello world\n");
#
# Two successive calls?
#
# printf("hello ");
# printf("world\n ");

What does that have to do with error checking?

# Or maybe three calls, where the middle one failed, for some obscure
# (and undetected by just staring at the output) reason?
#
# printf("hello ");
# printf("strange ");
# printf("world\n ");

For some absurd reason if I see the above code in the .c but I don't see
"strange " in the output, I manage to realize something went wrong without
checking anything else.

I guess I have ESP.


At best the return can indicate something went wrong. To get the details
you'll need more information. Oft times, you get more information by
printfing to the terminal window.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
We found a loophole; they can't keep us out anymore.