Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!ames!rex!uflorida!novavax!twwells!bill From: bill@twwells.uucp (T. William Wells) Newsgroups: comp.lang.c Subject: Re: C problems Keywords: Amiga, Manx 3.6a Message-ID: <1005@twwells.uucp> Date: 1 Jun 89 20:03:35 GMT References: <365@xdos.UUCP> <7511@bsu-cs.bsu.edu> Reply-To: bill@twwells.UUCP (T. William Wells) Organization: None, Ft. Lauderdale Lines: 31 Summary: Expires: Sender: Followup-To: Distribution: In article <7511@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes: : It seems like overkill, but not detecting a full device is a *very* : common bug in C programs. (However, a possible optimization is to call : ferror() just once before the output stream is closed instead of : testing the value from putc all the time.) Not quite: if you are going to do this, call fflush and then ferror and you still need to check the results of fclose. The fflush is needed so that the final write occurs; the fclose to deal with things like failing to update directory entries. (I suppose that the fclose should return error on a failure to write the final buffer, thus eliminating the need for any checks other than on the fclose, but several stdio implementations I've seen don't.) Even better is to determine some points in your program that don't occur too frequently, say <5% of the frequency of character writes, and call ferror there as well. That way you catch the error after only a few "file system full" messages get printed on the console rather than 600 billion. :-) Frequently, a good place for a text file is after each newline is written. The message printing, BTW, is a serious problem with some UNIX's: a good way to bring those systems to their knees is to get the kernel to generate an unending series of messages. What happens is that, since kernel message writing for these systems is polled, while a message is being written, nothing other than interrupts are processed. --- Bill { uunet | novavax } !twwells!bill