Re: errno variable on the Hurd (was: Re: Postgresql question)
On Fri, Jan 28, 2000 at 11:21:19AM -0800, Brent Fulgham wrote:
> 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.
Here's what Single Unix says on the subject:
# Many functions provide an error number in errno which has type int and
# is defined in <errno.h>. The value of errno will be defined only
# after a call to a function for which it is explicitly stated to be set
# and until it is changed by the next function call. The value of errno
# should only be examined when it is indicated to be valid by a
# function's return value. Programs should obtain the definition of
# errno by the inclusion of <errno.h>. The practice of defining errno
# in a program as extern int errno is obsolescent. No function in this
# specification sets errno to 0 to indicate an error.
# It is unspecified whether errno is a macro or an identifier declared
# with external linkage. If a macro definition is suppressed in order
# to access an actual object, or a program defines an identifier with
# the name errno, the behaviour is undefined.
I'm not sure exactly what is meant by ``obsolescent'' (deprecated but
not forbidden? so don't file ``bug reports'', file ``obsolescence
reports'' :-). But the second paragraph makes it clear that errno can
be a macro.
David A. Madore