casts to void

M.J.Shannon mjs at eagle.UUCP
Fri Aug 9 22:37:55 AEST 1985


> <Fnord>
> >The printf() function CAN FAIL and if you don't test for it,
> >Murphy says that it WILL fail, under the worst possible
> >circumstances (e.g., while updating YOUR pay record).
> >Instead of looking for ways to avoid testing printf return,
> >how about making your code more robust.
> 
> Come on.  What are you going to do about it if printf fails?  Especially
> if you know you're writing to the terminal, in which case you can't
> write an error message, either.  You want us to write:
> 
> main( ) {
>           if( printf( "Hello, world\n") < 0) {
>                     exit( -1) ; /* Ooops, can't write to terminal... */
>                     }
>           }
> 
> Personally, I think there ought to be a standard way to tell all or some
> of the library functions that if they get an error, they should just
> print an error message and die, 'cause usually that's all I'm going to
> do anyway (and usually won't.)
> 
>        Mark
> ^.-.^  Purtill at MIT-MULTICS.ARPA    **Insert favorite disclaimer here**
> (("))  2-032 MIT Cambrige MA 02139

I think the point is that every program that produces output should make an
attempt to verify that it all got out.  Besides, no program has any guarantee
that it's writing on a terminal (i.e., "hello >diskfile").  Would you prefer
that your favorite compiler not check that it indeed managed to write out the
assembly language it intended to?  It can happen that the assembler won't barf
on it, and the loader might (or might not, depending on a whole lot of things).
How do you track this one down (particularly in a large make script)?  The
problem is of course not limited to compilers.
-- 
	Marty Shannon
UUCP:	ihnp4!eagle!mjs
Phone:	+1 201 522 6063

Warped people are throwbacks from the days of the United Federation of Planets.



More information about the Comp.lang.c mailing list