Re: cvs commit: src/sys/sys errno.h

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Sun, Jul 03, 2005 at 04:11:01PM +0200, Simon 'corecode' Schubert wrote:
> you want to fight and fix all occurences of browkn programs out there?
> happy hacking. i prefer to fix *our* code.

I've been doing that, yes. Actually, they are not nearly as many programs
as you make it be. Those who do it are bitrot.

> > 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.
> 
> This is true. If you find a way to emit a warning if somebody declares
> 	extern int errno;
> it would be really good!

There is no way. Even if there would be one, it doesn't help since most of
the times (esp. for ports/pkgsrc builds) the warnings are just ignored anyway.

> > (b) It violates POLA. Why is "extern int errno;\n#include <errno.h>" different
> > from the reverse version?
> 
> because errno is a define. Like in *all* other major open source operating
> systems i could check (*BSD, Linux, OpenSolaris). why do i need to include
> sys/types.h before everything else? because.

You don't have to include sys/types.h before e.g. stdio.h. It's a bug in our
code that you have to do that, I intend to fix that. Don't mix this issues!

Actually, errno is NOT a define. Read C99, it's explicitly a macro. Defining
it explicitly is UNDEFINED behaviour. So yes, a program doing so does violate
the standard. The example I gave (extern int errno; #include <errno.h>) is
especially nasty, because it silently failed with the old implementation in
the sense that the code compiled but didn't work as soon as threading comes
into play. Now we get an error, either at compile time (with the errno.h before)
or at link time. I strongly prefer compile-time errors, because they can be
solved much easier.

> > (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.
> 
> our compiler doesn't complain. So maybe we should as well "fix" the compiler
> to deal with this issue.

Yes, we should. Just because it doesn't check this doesn't make the behaviour
any better. NO incorrect C in our header files, please. There have been enough
examples of how GCC behaviour created portability issues.

Joerg