[ubuntu/jaunty] conntrack 1:0.9.7-1.1ubuntu1 (Accepted)

[Colin Watson]

On Mon, Nov 24, 2008 at 03:56:39AM -0800, Steve Langasek wrote:
> On Mon, Nov 24, 2008 at 01:02:49AM +0000, James Westby wrote:
> > I have attacked a couple of these failures recently, and the thing I
> > always find hard is knowing what to do with an error condition. Without
> > knowing the code it is hard to know how an error should be handled.
> > For instance today I was looking at an ircd that wasn't checking the
> > return code on a write call, writing to its log file. I don't think
> > an error should abort, but in many cases that will be the only sensible
> > thing to do.
> 
> This is the obvious conclusion, and the one I mistakenly reached at first,
> too.  But the main reason it's a programming error to not check the return
> code on a write call is *not* because you need to always handle errors, but
> because you should handle *successes* in the form of partial writes:
> 
>        If  a  write()  is interrupted by a signal handler before any bytes are
>        written, then the call fails with the error EINTR; if it is interrupted
>        after  at  least  one  byte  has  been  written, the call succeeds, and
>        returns the number of bytes written.
> 
> write(2)
> 
> So using write() means you should always have retry handling in place.

Indeed. gnulib provides a full_write function that you can crib (in
GPLv3-compatible code, or otherwise study and reimplement, I suppose) if
you want to ensure that everything is written; or safe_write if you just
want to retry on EINTR but don't mind if not everything gets written,
which for example may be appropriate in code operating on non-blocking
file descriptors.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]