Date: Saturday, August 10, 2019
I think we should generalize EBADF to attempts to do something fd-ish on a port without a fd. So we raise on EBADF, but otherwise return #t or #f depending on the result of isatty().
ENOTSUP makes more sense.
My intuition says we shouldn't fabricate errno values for errors that don't have them. But I don't have anything concrete to back it up.
I think I'm using an unconscious heuristic that things should "do what it says on the tin". If something is named errno, it should come from errno. Simple policy is easy to understand and the division of responsibility is clear.
Right now we have to supply some existing errno value to error-errno when we're handed something bogus and have to raise an error. I'm assuming that we will be replacing this fake out with something more specific when this is broken out to its own SRFI prior to finalizing 170.
Replying to John below:
You mean return errno ENOTSUP if it's handed something like a string port? That's a useful errno, although the
plain description in POSIX sounds more like "It's potentially valid in POSIX, but this implementation can't do it":
[ENOTSUP]
Not supported. The implementation does not support the requested feature or value.
I agree with Lassi's reconsideration that tty? shouldn't raise an error if handed any port that's not closed (not sure I can distinguish that), for example a string port. Only raise an error if it's not handed a port, or if it has a file descriptor, that fd is handed to isatty, and isatty sets errno to EBADF. And per the above, don't change the errno to ENOTSUP.
I may dig deeper into Chibi Scheme's port implementation so I can better distinguish all this.
- Harold
----- Original message -----
From: John Cowan <xxxxxx@ccil.org>
Date: Saturday, August 10, 2019 4:55 PM
Actually, no I don't. ENOTSUP makes more sense.
I agree. I think we should generalize EBADF to attempts to do something fd-ish on a port without a fd. So we raise on EBADF, but otherwise return #t or #f depending on the result of isatty().
> Although there's the case when it's handed a port who's file descriptor
> is not valid, which would likely indicate something is terribly wrong,
> or the port was closed.
If these cases can be distinguished reliably, it makes sense to raise an
error for them. Setting "errno = 0" before the call may allow for that.
> Otherwise, I'll have my Chibi Scheme implementation only raise an error
> if it's not handed a port.
I agree this should raise an error. Also if it's a port that
intrinsically doesn't have an fd associated with it (e.g. your earlier
example, a string port).