Re: PATCH: Adhere to section 17.4.1.2 clause 5 of ISO 14882:1998

[Nathan Myers <ncm at nospam dot cantrip dot org>]

On Fri, Apr 06, 2001 at 08:06:51PM +0200, Gabriel Dos Reis wrote:
> Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes:
> | Assuming a liberal reading of this section, errno should be provided
> | as a macro even if the C implementation is something other than a
> | function or a macro (i.e. it is a global variable with external
> | linkage)...
> 
> There has been a discussion to that effect on comp.std.c++ recently,
> and Steve Clamage's reading 
> 	Message-ID: <3AB935DC.325E6AAF@sun.com>
> is that errno has an external linkage, thus it cannot be a macro
> name. 

I read the posting:  http://groups.google.com/groups?q=Steve+Clamage+errno

His argument seems to me to say the opposite: if errno is assumed _not_ 
be a macro, then the standard has contradictions; if you recognize it 
must be a macro, everything is OK.

In fact, as a party to the discussions at the time, I can assert that
it was perfectly clear to the participants in the library group that it 
had to be allowed to be a macro, and (therefore, like other such names) 
had to _be_ a macro.

Steve seems oddly nonplussed that the standard has no rationale why errno
must be a macro, despite that rationales are scarce in the standard.

The notion of errno as a global- or namespace-reserved name is what we 
always called a "red herring".  That it's reserved doesn't mean there's
any object that has the name.  The name is reserved, but only in the 
standard, so that no conforming user program can define it.  Since it's 
also a macro, you would have to #undef it first to try, but if you did, 
your program might not link, and in any case would be undefined. 

An implementation is free to define such an object, globally and/or in
std::, and even use it in its macro definition.  A user program can make 
no assumptions about whether it's there or not.  The standard certainly
doesn't define any such object; the implementation might choose to define 
that reserved name to erase your disk and impregnate your daughters, if 
mentioned.

Sun's implementation could be fixed by adding to their current definition
  namespace std { extern "C" { extern int errno; } }
a macro definition:
  #define errno ::std::errno
or even
  extern "C" int errno;
  #define errno ::errno

It would be doing Sun customers a favor to cause the construction
std::errno to be flagged as an error, because it's not portable.

One thing is clear: it takes some pretty sinuous weaseling to get 
from the standard anything other than that errno _must_ be a macro,
regardless of how it may also be defined otherwise.  

Nathan Myers
ncm at cantrip dot org