But, before doing any of this, I'd first consider rattling transarc's
cage a bit. I mean, really, null error codes?!
Yes, let's talk about error codes. There is another bug in the way errors
are returned by rx. In the file server at least, the server simply returns
a Unix errno to indicate an error. The problem is that errnos are not the
same across different implementations of Unix. ENOTEMPTY, for example, is
64 on some machines and 66 on others. I was very confused the first time I
saw "Identifier removed" (some kind of system V streams thing) being
returned by the file server.
This is important to me because it means
I can write programs that say "unknown user" vs "wrong password";
on a campus with over 35,000 users, the more precise
the feedback on errors I can provide to users, the better.
You don't want to get too precise. Unix traditionally makes no distinction
between "unknown user" and "wrong password," and even goes so far as to
insert a fake delay to simulate the password decryption when you enter a bad
user name. This is so crackers don't get any clues as to whether they've
entered a valid user name or not. I wouldn't automatically assume that the
null error message is a bug.
In our case, you can always verify a uniqname through other means, so the
null error message doesn't enhance our security all that much. But as an
extreme example, you wouldn't want an error message that says, "the password
you entered is too short by three characters, and the second character is
wrong."
