From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <2131834db7e388c1421257a88de93231@vitanuova.com>
From: C H Forsyth <forsyth@vitanuova.com>
Date: Thu,  3 Jun 2004 17:56:49 +0100
To: 9fans@cse.psu.edu
Subject: Re: Error reporting (Was: [9fans] GNU Make)
In-Reply-To: <67ce99a249859a0d4c3cd4502752ea7a@vitanuova.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 9449c6da-eacd-11e9-9e20-41e7f4b1d025

>>EIO might be better for unknown error codes than ENOENT.

     [EIO]              An I/O error occurred while making the directory entry
                        or allocating the inode for O_CREAT.

not really, since EIO would tend to suggest suggest (almost certainly
to a unix man and perhaps even me as well if i were to read it)
an actual error on a device (eg, bad block on drive), not an inability
to open an underlying file, and any programs that checked for it
would probably place that interpretation on it too.
at least ENOENT is honest when a file somewhere can't be accessed.
you'd be better off with EGREG (``something has happened that our little APE
can't communicate''), except that's not portable.

at any rate, it should be easier to see now why trying hard to change
things to make APE happy is not likely to produce the hoped-for joy and contentment.

it's not that there aren't enough integers in the world, more that
only a tiny subset is available as E numbers.  even with the extended
non-portable set in real Unix kernels the
E choice is pathetic for the things drivers might like to say.
of course, that does indeed lead to much tugging on hair and chins,
whilst trying to work out why a particular call failed.