[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
     http://www.eleves.ens.fr:8080/home/madore/ )

Reply to: