Re: error() or nil, 'error msg'

[Jay Carlson <nop@...>]

On Sep 18, 2014, at 5:48 PM, Sean Conner <sean@conman.org> wrote:

> It was thus said that the Great Jay Carlson once stated:
>> 
>> It is not so obvious what to do when f:flush() fails, since people discard
>> the return value.
> 
>  It's not so obvious what to do with f:flush() fails even *if* you check
> the return value.  I mean, what you reasonably do if it returns "No space
> left on device" and it's a daemon?  Or an application?  

f:flush() reports errors postponed from the time of f:write(). People don't check f:write()'s return value either. :-)

Back in the bad old days, bad blocks on floppies were common. Because of block device buffering, Linux would usually find out long after files had been closed. And I didn't really learn about fsync(2) until I started using XFS. :-( 

>  -spc (Error handling is hard!  Let's go shopping!)

On Solaris 2.4 or so, a Makefile kept blowing up with a segfault in /bin/cat. What?? How can /bin/cat segfault? Well, that particular /bin/cat (and stdio in general) liked to mmap() read-only files. You could copy a whole file with a single write(2) call. Except my files were on AFS, and the remote file server had bad blocks. Which, when write(2) got to them, reasonably caused a segfault when they could not be paged in.

To paraphrase Barbie again, an awful lot of Unix error handling bottoms out in "dead processes tell no tales."

Jay