Purtill@MIT-MULTICS.ARPA (Mark Purtill) (08/07/85)
<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
gwyn@BRL.ARPA (VLD/VMB) (08/07/85)
No, I want you to do something INTELLIGENT when a write operation fails. Properly-designed tools are NOT necessarily writing to a terminal with their printf()s; they may be writing into a disk file on a full filesystem or onto a communication link or a number of other possibilities. By assuming that your program is always being run in its simplest mode with a human attendant, you are providing your users with UNFRIENDLY software that will sooner or later cause them unnecessary grief. UNIX has enough crappy code already. Let's make OUR code better!
Purtill@MIT-MULTICS.ARPA (Mark Purtill) (08/08/85)
<Fnord>
1. Who says you're on UNIX anyway? UNIX may have uniform treatment of
I/O, but not all systems do, and some of them have C.
2. I'll conceed the point that usually you should do something when
printf fails. However, usually that is print an error message (or fail
to do so) and die. I claim the system should have some way of doing
that for me. Perhaps there should be an io error signal which has
default action of doing nothing (where-upon the routine in question
returns an error value) but can be reset to print an error and die.
Mark
^.-.^ Purtill at MIT-MULTICS.ARPA **Insert favorite disclaimer here**
((")) 2-032 MIT Cambrige MA 02139mjs@eagle.UUCP (M.J.Shannon) (08/09/85)
> <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.
peter@baylor.UUCP (Peter da Silva) (08/12/85)
> No, I want you to do something INTELLIGENT when a write operation fails. > Properly-designed tools are NOT necessarily writing to a terminal > with their printf()s; they may be writing into a disk file on a > full filesystem or onto a communication link or a number of other > possibilities. By assuming that your program is always being run OK. What should my whizzbang filter do when a write fails, other than write an error message and quit? I really shouldn't test to find out what stdout is, since I'm not supposed to behave any differently when I'm writing to a file than when I'm writing to a terminal... I could core dump, but what good will that do when it's out in the field? I can look at errno & see if that helps... maybe if I get an EINTR I should try to write again, but how do I know how much to write? Should I delve into _IOB[1]? Hey, maybe there's something to the 4.2 signals after all: they don't interrupt system calls! How about EIO? Since this can occur on the call after the one on which it occurs I oughta do a stack trace & see what I did last, so I can print a better error message before quitting. EBADF. Now that could be useful. Most likely it means SH didn't open stdout for me. Best not think about that. ENOSPC. No space left on device. Better unlink my output file & temp files before dying, if I have any, but I'm going to unlink my temp files anyway and I can't do an funlink(), 'cos there ain't no such thing. And besides the partial output may be of some use to someone. Any other suggestions? -- Peter da Silva (the mad Australian) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/15/85)
> OK. What should my whizzbang filter do when a write fails, other than > write an error message and quit? The canonical UNIX tool should write a message such as "prog: write failed" to stderr (which may be writable even though stdout has a problem), restore terminal modes if necessary, remove temporary files, etc. then exit with a non-zero status code (so that the invoker of the program can detect the problem and take whatever strategic measures are needed). Other more specialized programs may need to take other actions opon occurrence of an error. The important point is to DETECT that an error has occurred, then take appropriate steps (usually, REPORT it).
franka@mmintl.UUCP (Frank Adams) (08/15/85)
In article <361@baylor.UUCP> peter@baylor.UUCP (Peter da Silva) writes: >OK. What should my whizzbang filter do when a write fails, other than >write an error message and quit? Nothing. You should write an error message to stderr and quit. If the write to stderr fails, feel free to give up entirely. But don't fail to detect the error on the original write.
peter@baylor.UUCP (Peter da Silva) (08/18/85)
> > OK. What should my whizzbang filter do when a write fails, other than > > write an error message and quit? > > The canonical UNIX tool should write a message such as "prog: write > failed" to stderr (which may be writable even though stdout has a > problem), restore terminal modes if necessary, remove temporary files, > etc. then exit with a non-zero status code (so that the invoker of the > program can detect the problem and take whatever strategic measures > are needed). Good, that's what I hoped you'ld say. Now if I have no temporary files and don't change the terminal modes, that reduces to "perror(whatever); exit();". Now if you could define a routine "ioerr(errno, fp)" that did nothing in the standard stdio (except setting errno), then I could just define "ioerr(errno, fp) { perror(filenameof(fp), errno); exit(errno); } and l;eave all my printfs tidy. The implementation of "filenameof" is left to the reader. -- Peter da Silva (the mad Australian werewolf) UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076