A modest proposal for better errno values...
Jordan Hubbard
jkh at apple.com
Tue May 13 01:57:17 PDT 2003
Now, before I start here, let me just acknowledge up-front that what
I'm about to raise is prime bike-shed material of the first order. It
is a matter so trivial that it's not at all unreasonable to expect
every man and his dog in this project to have a strong opinion on it,
so in the name of bandwidth conservation and all that's holy I merely
ask you to honestly ask yourself "do I really, truly care about this?"
before sending off your personal 500 word screed on the subject that's
to follow. Finally, and just for the record, I'll note that two of my
dogs pretty much agree with me on this and the third, a small white
poodle with an attitude problem, honestly doesn't give a damn and
indicated as much by merely showed me his teeth when I asked him about
it.
With all that out of the way, I'll get on with it. Here at Apple we've
been merging this and that from FreeBSD, as is our usual custom, and
today several engineers saw something go across in a cvs merge commit
which raised more than a few eyebrows and led to various queries as to
the origin of the following new errno in FreeBSD:
jkh at freebsd-> grep DOOFUS /usr/include/sys/errno.h
#define EDOOFUS 88 /* Programming error */
Doing a little digging, I also see that a certain Dane is responsible
for both the original commit on 2002/08/09 and a spelling fix to it on
2002/08/21 (I guess the OED is pretty clear on the spelling of
"doofus"). Most of you who know me at all will also know that I'm
hardly the most reverent or humor-impaired person you'll ever meet and
I certainly got a chuckle out of this when I first saw it, just as I've
gotten a chuckle out of various man pages and function names in FreeBSD
which showed that the programmer responsible for them was at least
enjoying his or her work at the time. I'm all for that, particularly
in situations where a developer or user has to go well out of their way
to get offended by something and therefore isn't exactly an object of
sympathy.
This, however, is a little more in-your-face than something like the
infamous "die_you_gravy_sucking_pigdog()" function in shutdown (which I
successfully defended when it came up) since it sort of makes an
implied statement about the developer's competence, rightly or wrongly,
and is far more likely to propagate into other code since if there's an
errno value returned by something then it also needs to be checked by
the client code. From the corporate perspective, and corporations are
infamous for not being particularly inclined towards humor, this is one
particular little "easter egg" in FreeBSD that sticks just a little too
far above the ground to lend a professional image.
So, to make a long story short, this is one small area where Apple's
going to have to gratuitously diverge from FreeBSD if it remains this
way and I frankly hate that idea since it just makes diffing things
that much more annoying and for reasons which could be best and most
accurately described as "silly." That said, I'm sure the reactions
of the various people reading this will still vary between "who gives a
damn what Apple thinks of our errno values?! Get a life, Apple!" and
"yeah, that's a pretty silly errno value and in rather colloquial
english at that, let's pick a more descriptive name like ``EUSERERR''
or something which makes any code using it more clear."
I'm naturally hoping that more people will be of the latter opinion and
we can just change it and move on, one more gratuitous and unnecessary
code fork thus averted, but if the group consensus is that we should
get bent and simply change our own value to one which potentially
offends our developers less (or remove it entirely) and not bother the
FreeBSD project with such requests, I'm willing to live with that too.
I had to at least ask, however, rather than just making the change
unilaterally on our side... Thanks, and let the bikeshed building
begin!
--
Jordan K. Hubbard
Engineering Manager, BSD technology group
Apple Computer
More information about the freebsd-hackers
mailing list