cvs commit: src/sys/sys errno.h

Joerg Sonnenberger joerg at britannica.bec.de
Sun Jul 3 06:33:56 PDT 2005


On Sat, Jul 02, 2005 at 04:20:49PM -0700, Matthew Dillon wrote:
>     The change stays in for now.  As was said earlier... we've run into a
>     concrete wall.  Too many third party programs are being broken.  This 
>     is the only way we can make errno use TLS storage and still remain sane.
> 
>     We may be able to remove it a year or two or three from now, or if 
>     someone wants to make a concerted effort to get all the third party
>     software sources to fix their code... then we can remove it.  But for
>     now we need to move on.

Oh, come one Matt. I know that you know that the world doesn't work that way.
most programmers work follow the principle of least resistence. It ain't broken
since it compiles fine.

I object this chance for three reasons:
(a) it hides problems. that's *never* a good thing and that will result in
upstream code not getting fixed.
(b) It violates POLA. Why is "extern int errno;\n#include <errno.h>" different
from the reverse version?
(c) It violates ISO C for those programs it tries to "fix". Yes, read again.
It just doesn't work this way.

#include <errno.h>

extern int errno;

expands to something like this:
static inline int *
__error(void)
{
}

extern int *__error();

That's invalid C, since the same symbol has both static and extern visibility.

Speaking about breakage, this is a typical example of bitrot and with the exception
of perhaps Perl all other programs simple don't need the define at all.

For all those reasons, I want it backed out.

Joerg





More information about the Commits mailing list