Date: Tue, 13 May 2003 07:32:23 -0700 (PDT) From: Frank Mayhar <frank@exit.com> To: Gary Jennejohn <garyj@jennejohn.org> Cc: Jordan Hubbard <jkh@apple.com> Subject: Re: A modest proposal for better errno values... Message-ID: <200305131432.h4DEWNLZ025624@realtime.exit.com> In-Reply-To: <200305131101.h4DB1SKo005541@peedub.jennejohn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Gary Jennejohn wrote:
>
> Bob Bishop writes:
> > Hi,
> >
> > At 09:57 13/5/03, Jordan Hubbard wrote:
> > >[stuff]
> > >#define EDOOFUS 88 /* Programming error */
> > >[more stuff]
> >
> > Before the noise becomes unbearable, I have a question:
> >
> > Why isn't EINVAL appropriate to the case in question?
> >
> If you look at the 4 places where it's in the tree it's pretty clear that
> returning EDOOFUS is meant to rub the programmer's nose in a coding error
> (recursive malloc() calls, etc).
>
> At least the error string ("Programming error") is reasonable.
>
> I agree that the name isnt' too happily chosen and should be changed to
> something more neutral before it shows up in more places in the tree.
Um, no. If it were "EFUCKHEAD" or "EIDIOT" maybe, but EDOOFUS is about
as inoffensive as it comes.
But I have a better idea: Why doesn't the committer in question actually
fix the problem, so that instead of four places, there are no places? Seems
like this would eliminate the error as well as the reason _for_ the error.
In other words, this bikeshed is aimed at absolutely the wrong target.
Sigh.
--
Frank Mayhar frank@exit.com http://www.exit.com/
Exit Consulting http://www.gpsclock.com/
http://www.exit.com/blog/frank/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200305131432.h4DEWNLZ025624>