WG15 Defect Report Ref: 9945-1-54
Topic: extern int errno


This is an approved interpretation of 9945-1:1990.

.

Last update: 1997-05-20


                                                                9945-1-90 #54
	Classification:  No change

 _____________________________________________________________________________


	Topic:			extern int errno
	Relevant Sections:	2.4


Defect Report:
-----------------------

On page 23, section 2.4, on line 502, the POSIX standard specifies the
attributes that are required for the 'errno' variable. The lines states:

	extern int errno;

This is expressed as a specific 'C' declaration. I believe that this is
overly specific, and only represents a short hand notation. Other areas within
this standard do not use this format, as in the 'stat' structure in section
5.6.1.

I believe that the description should be spelled out as being

	an expression representing an assignable integer variable
	with global scope

or

	expands to a modifiable lvalue of type int

This will permit the declaration that is specified, while also permitting
other implementations which satisfy the same need. To get the values that
are returned in this variable, <errno.h> must be included, and that is
typically where the 'errno' variable is typically defined.

This same topic has also come up in the POSIX.4a working group and is
mentioned in the latest drafts in section 2.5.2. They propose specific
alteration of the standard; I propose an interpretation that permits
flexiability in the declaration and may also solve the problem the P1003.4
group is attempting to solve.

Attached is a note that I received from one of the members of the P1003.1
Working Group. It gives a different perspective on the problem and the history
of the text in the standard.


(Paul Wanish)
----------------------------------------------------------------------------
Text of Note
------------

The POSIX C bindings should use exactly the ISO C definition of errno, which
says that errno "expands to a modifiable lvalue of type int." This ALLOWS an
implementation to do something like:

 #define errno (*__errno_val)
 extern int *__errno_val;

but also allows the more traditional definition of just "extern int errno".

The main difference between ISO/IEC 9945-1:1990 and ISO C is that POSIX explicitly
allows an application to contain the statement:

 extern int errno;

I believe that this would even be allowed if the application didn't include
<errno.h>. This is different than ISO C, and means:

(1) A straight ISO C application still is OK under POSIX.1.
(2) An implementation that sticks with ISO C is OK under POSIX.1.
(3) An application that includes "extern int errno" is OK under POSIX.1
    but not ISO C.
(4) An implementation that defines errno as a preprocessor define is OK
    under ISO C but not POSIX.1.

This definition was put into ISO/IEC 9945-1:1988 primarily to accomodate Common
Usage C implementations and existing applications. There existed (and still
exist?) many historical applications that didn't bother to include <errno.h>,
but just defined errno themselves. This was common practice, and the
committee could not reach a concensus on requiring them to change. (Also,
frankly, I don't think that anyone had any idea of why it might be a good
idea to define things the ISO C way, at least in the U**X world.) The "no
substantive change" rule precluded this being changed in :1990.

However, time has passed. ISO C compilers are edging out older compilers,
and the disadvantages of the POSIX definition of errno is becoming clear.
It's time to change it.


WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------

ISO/IEC 9945-1:1990 specifies that

  extern int errno;

is the correct declaration for errno.  This is not a shorthand
for a different meaning.

Rationale for Interpretation:
-----------------------------

The standard means exactly what it says.

This issue has been resolved in the manner suggested by
the requester in ISO/IEC 9945-1:1996, which is now
in ballot.
 _____________________________________________________________________________