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