(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]

In article <11**********************@g44g2000cwa.googlegroups .com>,
whatluo <wh*****@gmail.com> wrote:

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.

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]

In article <11**********************@g44g2000cwa.googlegroups .com>,
"whatluo" <wh*****@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

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]

Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
# In article <11**********************@g44g2000cwa.googlegroups .com>,
# "whatluo" <wh*****@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]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:

Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
# In article <11**********************@g44g2000cwa.googlegroups .com>,
# "whatluo" <wh*****@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");

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]

"whatluo" <wh*****@gmail.com> wrote:

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.

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]

"P.J. Plauger" <pj*@dinkumware.com> wrote:

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.
No, because of those reasons, and more, it is a Bad Thing to write
(void) casts and also a Bad Thing to cast malloc().
Go figure.

Furrfu.

Richard

[Bhatnagar Achindra]

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]

> 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.

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]

No Such Luck wrote:

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.

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?

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>

--
Er*********@sun.com

[Jens.Toerring]

Bhatnagar Achindra <ac******@gmail.com> wrote:

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
I guess you meant "( void ) printf( .... )", didn't you?
return values before moving to the next statement, thus we clean up any
possibility of fetching the return value.
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.
Positive values from the function call specifies the number of bytes
written to STDOUT, excluding '\0' in general,
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.
while a negative value tells the error code if occured.

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 ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[CBFalconer]

Je***********@physik.fu-berlin.de wrote:

Bhatnagar Achindra <ac******@gmail.com> wrote:
.... snip ...

Positive values from the function call specifies the number of
bytes written to STDOUT, excluding '\0' in general,

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.

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

--
Some informative links:
news:news.announce.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]

CBFalconer <cb********@yahoo.com> wrote:

Je***********@physik.fu-berlin.de wrote:

Bhatnagar Achindra <ac******@gmail.com> wrote:
... snip ...

Positive values from the function call specifies the number of
bytes written to STDOUT, excluding '\0' in general,

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.

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

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 ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Keith Thompson]

"No Such Luck" <no*********@hotmail.com> writes:

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.

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?

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_Keith) ks***@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]

Giorgos Keramidas <ke******@ceid.upatras.gr> wrote:
# SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> writes:
# >Christian Bau <ch***********@cbau.freeserve.co.uk> wrote:
# ># In article <11**********************@g44g2000cwa.googlegroups .com>,
# ># "whatluo" <wh*****@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.

[SM Ryan]

"No Such Luck" <no*********@hotmail.com> wrote:
# > 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.
#
# 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?

What I'm wonderring is how do you report an error if printf doesn't
work? I usually use printf or fprintf or perror to print errors. If
the printf doesn't work how do you report the printf doesn't work?

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Who's leading this mob?

[Gordon Burditt]

>What I'm wonderring is how do you report an error if printf doesn't

work? I usually use printf or fprintf or perror to print errors. If
the printf doesn't work how do you report the printf doesn't work?

Use printf(). The rule here is that *IF* the problem is running out
of disk space, that you have to keep reporting the error so often
that even if some disk space is freed up, it's immediately used again.
This is called the error-retentive approach, and any resemblance to
anal-retentive is strictly non-coincidental.

For POSIX fans:

while (printf(...error message goes here...) < 0){
fork();
}

Gordon L. Burditt

[S.Tobias]

SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:

Giorgos Keramidas <ke******@ceid.upatras.gr> wrote:

Two successive calls?

printf("hello ");
printf("world\n"); What does that have to do with error checking?
printf("do not ");
printf("fire weapon\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");

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.

Who says you'll be able to see the output?

--
Stan Tobias
mailx `echo si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[SM Ryan]

go***********@burditt.org (Gordon Burditt) wrote:
# >What I'm wonderring is how do you report an error if printf doesn't
# >work? I usually use printf or fprintf or perror to print errors. If
# >the printf doesn't work how do you report the printf doesn't work?
#
# Use printf(). The rule here is that *IF* the problem is running out
# of disk space, that you have to keep reporting the error so often
# that even if some disk space is freed up, it's immediately used again.
# This is called the error-retentive approach, and any resemblance to
# anal-retentive is strictly non-coincidental.
#
# For POSIX fans:
#
# while (printf(...error message goes here...) < 0){
# fork();
# }

On some kernels you need a sleep in there. Some kernel abort processes
if there are too many forks too quickly.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Don't say anything. Especially you.

[SM Ryan]

"S.Tobias" <si***@FamOuS.BedBuG.pAlS.INVALID> wrote:
# SM Ryan <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote:
# > Giorgos Keramidas <ke******@ceid.upatras.gr> wrote:
#
# > > Two successive calls?
# > >
# > > printf("hello ");
# > > printf("world\n");
#
# > What does that have to do with error checking?
#
# printf("do not ");
# printf("fire weapon\n");

The navy has a practice that you repeat orders back to verify they've been
heard correctly. If you're doing safety critical programming, merely trusting
the return of printf is stupid. You would have to add extra layers of
read back and feedback to verify correct transmission.

Unless you're debugging a program error, testing the return of printf is
either overkill (because the output is its own trace), or woefully inadequate.

# > > 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.
#
# Who says you'll be able to see the output?

Who says I won't? And if the disk has a track limit, the operating
system lets me know. If I'm really doing critical operations and
need to know precise status, I would use write() so that I can
skip bufferring effects and know precisely what the kernel has
gotten and when it has gotten it.

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

[Malcolm]

"SM Ryan" <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote

What I'm wonderring is how do you report an error if printf doesn't
work? I usually use printf or fprintf or perror to print errors. If
the printf doesn't work how do you report the printf doesn't work?

exit(EXIT_FAILURE);

[Malcolm]

"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote

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.

You have a point here.

printf() is actually a bad example, since everyone knows what the fucntion
does, and that it is unusual to be interested in the return value.
However if functionx return a value, then normally you would expect that
value to be useful. It is quite common for functions to return error codes,
and for sloppy programmers to neglect to check the error. So an explicit
cast would be useful.

The problem is that if you impose this a standard then the sloppy
programmers might just get into the habit of writing (void) anyway.

(void) functionx(x, y);

is also hard on the eye.
By itself the cast doesn't detract too much from readbility, but just look
at this

(void) glib_MoveMouseCursor( (float) cursor.x_loc, (float) cursor.y_loc);

Now we've got something pretty unreadable, highly error-prone, and what is
making it that way is the casts and structure member names that are intended
as aids to the programmer.

[CBFalconer]

Malcolm wrote:

"SM Ryan" <wy*****@tango-sierra-oscar-foxtrot-tango.fake.org> wrote

What I'm wonderring is how do you report an error if printf doesn't
work? I usually use printf or fprintf or perror to print errors. If
the printf doesn't work how do you report the printf doesn't work?

exit(EXIT_FAILURE);

I had a medical message system some years ago. It delivered test
results to nursing stations. All messages were inserted with an
'alternate destination', such as the floor supervisor. If delivery
(and retries over a configured time limit) failed the message was
wrapped with a header identifying it as rerouted and sent to the
alternate location. The same rules applied here, implemented by
making the reroute wrapper set the alternate to the system
console. If that also failed the machinery was busted, and
probably wasn't accepting the messages from the mainframe in the
first place.

Just as an illustration of handling output failure.

--
Some informative links:
news:news.announce.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

[Malcolm]

"No Such Luck" <no*********@hotmail.com> wrote

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?

It depends on your application. A video game is either playable or it isn't,
and usually you have no facilities for issuing patches, so no error messages
are produced. An error message just irritates the customer when he calls
only to be told "yes it was our fault but we can't do anything about it".

If you are writing embedded software for a life-support system, on the other
hand, you probably want a detailed log of every little thing that goes
wrong, and you would have a list of customers whom you would contact in the
event of a problem being reported. The customer would usually have a trined
technician who could roll back to a stabler previous version, or shut off
certain functions, if the problem was serious enough.

[mcp_achindra]

(void) printf(...) Vs printf(...)

Well I think I figured out, what it all means. We have been running
all the way on the wrong tracks.

The ANSI/ISO C Standards Documentation - States

"Portable Codes - Strictly Conforming"

- only uses specified features
- doesn't exceed any implementation-defined limits
- has no output that depends on implementation -defined, unspecified
or undefined limits.

This intends to describe maximum portable programs, which will always
produce same output, what ever they are run on.

To make a program portable, one must put the necessary casts, return
values adn so on.

Thus it is now clear thet (void) printf(...) Vs printf(...) is merely
an implementation issue and this makes the code portable over various
platforms.

[Eric Sosman]

mcp_achindra wrote:

(void) printf(...) Vs printf(...)

Well I think I figured out, what it all means. We have been running
all the way on the wrong tracks.

The ANSI/ISO C Standards Documentation - States

"Portable Codes - Strictly Conforming"

- only uses specified features
- doesn't exceed any implementation-defined limits
- has no output that depends on implementation -defined, unspecified
or undefined limits.

This intends to describe maximum portable programs, which will always
produce same output, what ever they are run on.

To make a program portable, one must put the necessary casts, return
values adn so on.

Thus it is now clear thet (void) printf(...) Vs printf(...) is merely
an implementation issue and this makes the code portable over various
platforms.

It's not about portability, but about documentation.

C has various kinds of statements: return, if, { blocks },
and others. One frequently-used type of executable statement
consists only of an expression followed by a semicolon, as in

x = 3; /* the `=' operator and two operands */
i++; /* the suffix `++' operator and one operand */
f(); /* the `()' operator and one operand */

The interesting thing about an expression is that it yields
a value. Yes, even the `=' operator produces a value, in addition
to the effect of storing something: in `x = 3;' the value of the
entire expression is three, converted to the type of `x'.

Sometimes you don't care about the value of an expression;
you evaluate it only for its side-effects. You probably write
`x = 3;' just to store a new value in `x', making no use of the
expression's value. You probably write `i++;' just to increment
`i', and you don't use the previous value (which is the value
of the expression) at all. You probably write `f();' just to
accomplish whatever side-effects the function produces, not
caring about the value it returns.

... and that's where the `(void)' casts come in. The printf()
function returns a value: either the number of characters that
were printed, or a negative value to indicate an output error.
You frequently don't care how many characters were printed, and
you may not feel like checking for errors (either through general
sloppiness or because you plan to check with ferror(stdout) later
on). Yet, the function actually does return a value -- and some
source-checking tools like lint will issue all kinds of warnings
about ignoring that value. This can have the unpleasant effect of
producing so many warnings about printf() calls that the important
messages just get lost in the flood.

So you write `(void)printf(...);' as a way of "using" the
returned value: you "use" it by throwing it away, which has the
effect of ignoring it but is more explicit. "Quiet, lint," you
are saying, "I know that I'm ignoring the value, and it's not
an oversight you should complain about." The program does the
same thing with or without the `(void)' cast, so there's no
issue about portability; the cast amounts to documentation that
tells lint -- or a human reader -- that you really intended to
ignore the returned value.

Personally, I think such casts are just unpleasant clutter:
the way to silence lint-like tools is to make the tools smarter,
not to cater to their nervousness. But some coding standards
require such things (and the position is not unreasonable; maybe
one *should* pay attention to the possibility that the output
never went anywhere), so I can't really make a cast that the
`(void)' cast is a Bad Thing. You pays your money, and you takes
your choice.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Keith Thompson]

ac***************@gmail-dot-com.no-spam.invalid (mcp_achindra) writes:

(void) printf(...) Vs printf(...)

Well I think I figured out, what it all means. We have been running
all the way on the wrong tracks.

The ANSI/ISO C Standards Documentation - States

"Portable Codes - Strictly Conforming"

- only uses specified features
- doesn't exceed any implementation-defined limits
- has no output that depends on implementation -defined, unspecified
or undefined limits.

This intends to describe maximum portable programs, which will always
produce same output, what ever they are run on.
Yes, but this has nothing to do with casting the result of printf.
To make a program portable, one must put the necessary casts, return
values adn so on.
No.
Thus it is now clear thet (void) printf(...) Vs printf(...) is merely
an implementation issue and this makes the code portable over various
platforms.

No, it doesn't make the code more portable. The statements
printf("hello, world\n");
and
(void)printf("hello, world\n");
are exactly equivalent; they both invoke the printf() function with the
specified argument and ignore the result.

Casting the result makes it more explicit to the reader that you're
ignoring the result returned by the printf function, but there's no
difference as far as the compiler is concerned.

The cast might inhibit a warning from some over-eager compiler or from
a lint-like tool, but that's not a portability issue. No compiler
will accept one and reject the other.

--
Keith Thompson (The_Other_Keith) ks***@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.

[achindrabhatnagar]

Portable Code should be strictly-conforming

strictly-conforming- A strictly-conforming program is one that:

· only uses specified features.
· doesn't exceed any implementation-defined limit.
· ***has no output that depends on implementation-defined,
unspecified, or undefined features.***

This was intended to describe maximally portable programs, which will
always produce the identical output whatever they are run on. For
example, the following program is not strictly conforming:

#include <limits.h>
#include <stdio.h>
int main() { (void) printf("biggest int is %d", INT_MAX);
return 0;}
/* not strictly conforming: implementation-defined output! */

Program portability is valuable, so we should always put the necessary
casts, return values, and so on in your real-world code.

conforming- A conforming program can depend on the nonportable
features of an implementation. So a program is conforming with respect
to a specific implementation, and the same program may be nonconforming
using a different compiler. It can have extensions, but not extensions
that alter the behavior of a strictly-conforming program. This rule is
not a constraint, however, so don't expect the compiler to warn you
about violations that render your program nonconforming!

The program example above is conforming.
I believe... (void) printf(...) is a matter of Understandability!

The KEY POINT of this whole text is to show that the fundamental
difference between correctness and understandability. If we lose
understandability in an attempt to gain correctness, we will lose in
the end.

Always place understandability as a priority ABOVE correctness. In the
end, if a program is more understandable, the chances it can be fixed
correctly will be much higher.

[Keith Thompson]

ac***************@gmail.com writes:

Portable Code should be strictly-conforming

strictly-conforming- A strictly-conforming program is one that:

· only uses specified features.
· doesn't exceed any implementation-defined limit.
· ***has no output that depends on implementation-defined,
unspecified, or undefined features.***

This was intended to describe maximally portable programs, which will
always produce the identical output whatever they are run on. For
example, the following program is not strictly conforming:

#include <limits.h>
#include <stdio.h>
int main() { (void) printf("biggest int is %d", INT_MAX);
return 0;}
/* not strictly conforming: implementation-defined output! */
It's also implementation-defined whether the program produces any
output at all. Add a \n to the end of the string literal.
Program portability is valuable, so we should always put the necessary
casts, return values, and so on in your real-world code.
Casts are rarely necessary; the cast in the above program is certainly
not necessary. It does make it explicit that the value returned by
printf() is ignored.
conforming- A conforming program can depend on the nonportable
features of an implementation. So a program is conforming with respect
to a specific implementation, and the same program may be nonconforming
using a different compiler.
Ok.
It can have extensions, but not extensions
that alter the behavior of a strictly-conforming program.
I think you mean that a conforming *implementation*, not a conforming
program, can have extensions.
This rule is
not a constraint, however, so don't expect the compiler to warn you
about violations that render your program nonconforming!
If a conforming implementation accepts your program, then it is a
conforming program by definition. The class of "conforming programs"
actually turns out not to be a very useful concept.
The program example above is conforming.
I believe... (void) printf(...) is a matter of Understandability!

The KEY POINT of this whole text is to show that the fundamental
difference between correctness and understandability. If we lose
understandability in an attempt to gain correctness, we will lose in
the end.

Always place understandability as a priority ABOVE correctness. In the
end, if a program is more understandable, the chances it can be fixed
correctly will be much higher.

I *think* the point of your article was that
(void)printf("whatever\n");
is better than
printf("whatever\n");

There is no difference between them in terms of conformance or
portability, so I'm not sure why you spent so much time discussing
them.

As for understandability, I personally find the statement clearer
without the cast. Any C programmer should know perfectly well that if
a printf appears in a statement context, the result is discarded.
It's common practice *not* to explicitly cast the result of printf().

--
Keith Thompson (The_Other_Keith) ks***@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.

[pete]

ac***************@gmail.com wrote:

Portable Code should be strictly-conforming

I disagree.
Portable Code should be Correct Code.

ISO/IEC 2382-l : 1993 (E/F)

01.04.06 01.04.06
portability (of a program)
The capability of a program to be executed on various types
of data processing systems without converting the program
to a different language and with little or no modification.

--
pete