The danger of specific errno values
One of the things I've learned the hard way in writing Unix programs is that you should almost never expect to know all of the errno values that system calls can return. In theory it's documented in the manpages, but in practice a manpage's list is never comprehensive. The safest thing to do is to assume that any system call can return almost any errno value.
The example I remember most vividly is that our SMTP server daemon
used to carefully check the result of
accept(). If there was an
error and it was anything besides
EAGAIN, the daemon decided that
something was undoubtedly broken and therefor it should die.
Unfortunately, it turns out that on some systems
accept() can also
ECONNRESET, because people can initiate a TCP connection and
then terminate it before the SMTP daemon gets a chance to
the new connection.
Until we caught this and fixed it, the result was that every so often (usually under periods of high load), the daemon would die mysteriously. Whoops.
This also points out another danger with checking specific errno values: they can change over time. So even code that was perfect and correct when it was written can drift into having problems over time and new systems, unless you recheck and revise it all the time.
(Our SMTP server daemon's code was probably perfectly correct for BSD systems of the early 1990s, for example.)