Incorrect error message

[Kragen Sitaker]

In article <xKzy4.1284$74.20176 at newsc.telia.net>,
Fredrik Lundh <effbot at telia.com> wrote:
>Kragen Sitaker <kragen at dnaco.net> wrote:
>> >in this case, the combination is a bit misleading, but
>> >there's no reasonable way to avoid this.
>>
>> Is it less reasonable to produce a misleading error message or to
>> duplicate fopen's functionality using fdopen?
>>
>> I suppose he who has time to complain has time to submit patches . . .
>
>if you can tell me how to work around this issue *without*
>duplicating the C library code in the Python interface, I can
>submit the patches...

The thought I had was to use open() and fdopen(), essentially
duplicating the C code for fopen(), but with better error reporting.
At least for the Unix world, that seems more reasonable to me than
reporting a misleading error.

For what it's worth, though, I can't think of any platform where
fopen() would die with EINVAL because of the filename; on Linux with
glibc2.1, according to the man pages, the error list (with causes) is:

EEXIST -- file exists (probably can't happen) (filename)
EISDIR -- file exists and is a directory (filename + mode)
EACCES -- access denied (filename or filename + mode)
ENAMETOOLONG -- (filename)
ENOENT -- file doesn't exist (filename or filename + mode)
ENOTDIR -- file isn't a directory (probably can't happen) or the directory
	you said it was in isn't a directory (filename)
ENXIO -- see manpage (filename + mode)
ENODEV -- see manpage (filename)
EROFS -- read-only filesystem (filename + mode)
ETXTBSY -- somebody's running it (filename + mode)
EFAULT -- segmentation fault (filename)
ELOOP -- symlink loop (filename, or 
	with O_NOFOLLOW (can't happen?) filename + mode)
ENOSPC -- no space on device (filename + mode)
ENOMEM -- kernel memory exhausted (???)
	also can come from malloc() failing
EMFILE -- too many files open in process (???)
ENFILE -- too many files open on system (???)
EINVAL -- invalid open mode

I guess figuring out what to return in the error is more difficult than
it looked.  Maybe the thing to do is simply return both the mode and
the filename for all open() exceptions.  Is it possible to do that in a
backward-compatible way?

-- 
<kragen at pobox.com>       Kragen Sitaker     <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08.  Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either.  :)