RE: errno variable on the Hurd (was: Re: Postgresql question)

[Brent Fulgham <brent.fulgham@xpsystems.com>]

> On Fri, Jan 28, 2000 at 09:36:30AM -0800, Brent Fulgham wrote:
> > Errno seems problematic on the Hurd for some reason.  I've seen
> > a few cases where the header has needed to be added to source
> > files for a clean compile, whereas it was not needed on other
> > environments (such as Linux).
> 
> Of course, using errno without including <errno.h> is the 
> Wrong Thing (tm).
> 
> There is a good reason, too:
> 
> /* Declare the `errno' variable, unless it's defined as a macro by
>    bits/errno.h.  This is the case in GNU, where it is a per-thread
>    variable.  This redeclaration using the macro still works, but it
>    will be a function declaration without a prototype and may trigger
>    a -Wstrict-prototypes warning.  */
> #ifndef errno
> extern int errno;
> #endif
>  
> and in bits/errno.h:
> 
> /* errno is a per-thread variable.  */
> #include <hurd/threadvar.h>
> #define errno   (*__hurd_errno_location ())
> #define __set_errno(val) errno = (val)
> 
> So it is a macro and not an extern int variable, which is why 
> the linker can't see it.
> 
Ahh -- this makes  a lot of sense now.  So we should probably file
bugs upstream against software that makes use of errno without including
the errno header file in a particular module/source file.  I think
there's a lot of stuff out there that relies on the belief that it's
an `extern int`, which is (as we now know) not always the case.

-Brent