fflush after every fputs, etc., seems a bad idea as it discards the
buffering benefit of stdio in avoiding write(2) and its syscall
overhead.  But checking fputs's return value, and all the other fprintf,
etc, is fine as it can still return `disk full', along with other
errors, and save effort by breaking the loop.

stdio errors are sticky.  If fputs("a\n") write(2)s and gets `disk
full', and then fputs("b\n") write(2)s and doesn't, the FILE still has
its error indicator set.  So the error isn't lost by checking fclose in
done().

An fclose(stdout) would return any error without having to fflush() and
ferror().  stderr would still need the fflush() and ferror() because
otherwise file descriptor 2 would be close(2)d by the fclose().

freopen(3) does discard any existing error state, so a call to it is a
contender for fflush+ferror before the freopen.

As for dying in the middle of an inc(1) due to the scan having trouble,
that already happens thanks to SIGPIPE, e.g. `inc | sed 42q', or more
likely `inc | less' and not reading all the input.  And I think that's
fine.  (Perhaps the inc should happen silently, and then a scan follow.)

I'm OK with calling them at the end.  Maybe we'd miss an odd error, but it's better than what we have now (where now is before my last commit).

I added a fflush() after each fputs() to be sure to not lose the error.  And that would be easy to turn into a macro.  But, not the best approach in terms of performance.  Any other ideas?

Oh, I think commit a scan fix now.  No point waiting for some day when
it's all going to be fixed in step.  This bug was mainly about using
/dev/full in our tests so we shake some of these problems out and tackle
the important ones;  those, like scan, where a user might think they've
got the useful data saved and delete the email.

fputs(3) is stdio.h so uses buffering.  When a write(2) is attempted, either
during or after the fputs(), the full disk will be seen.  A pending write()
can be forced with fflush(3) or fclose(3), amongst others.  A `sticky' error
from an earlier action can be tested for with ferror(3), though errno might
have been trampled by something else by then.

stdout to a TTY would be line buffered.  I'm guessing it's not with /dev/full
so, with the test program, the write() isn't happening before fputs() returns
that all is well.

    $ date >/dev/full
    /bin/date: write error: No space left on device
    $ echo $?
    1
    $ scan . >/dev/full
    $ echo $?
    0

packf(1) does check.  Others may or may not.  Could do with using /dev/full, if it's available, for more make-check tests.