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