Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!gnu From: gnu@sun.uucp (John Gilmore) Newsgroups: net.lang.c,net.news,net.bugs Subject: Not checking printf's result causes another news bug Message-ID: <2638@sun.uucp> Date: Thu, 15-Aug-85 00:50:47 EDT Article-I.D.: sun.2638 Posted: Thu Aug 15 00:50:47 1985 Date-Received: Mon, 19-Aug-85 08:38:44 EDT References: <11@brl-tgr.ARPA> <1288@eagle.UUCP> <15908@watmath.UUCP> Organization: Sun Microsystems, Inc. Lines: 21 Xref: watmath net.lang.c:6070 net.news:3817 net.bugs:664 > > 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). > > /usr/lib/news/expire uses fprintf to re-write the active file. It > didn't take the time to check the return value, and happened to run > one night when /usr was full. Result -- a 0 length active file and > a great deal of unhappy news software. printf (and fprintf) DO FAIL! Furthermore, the code in readnews/vnews that implements the "s" command (save a message to a file) does not check. The result is that a day's worth of [manually] archived net.sources stuff ended up as zero length files, when my net.sources file system filled up -- with no error messages at all. Luckily I noticed the empty files before the original messages expired. For the people asking "well what can I do if printf returns an error": how about printing an error to standard error and stopping? That's better than letting the data be thrown away without warning. (Interactive programs like vnews should, of course, not "stop" but should print a message and go back to the command interpreter.)