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