GCC 3.0.2: errno conflict.

GCC 3.0.2: errno conflict.

[Maxim Dementiev]

Excuse me if this bug is wellknown for peaple.
This code copile with error by g++ 3.0.2 on Linux 2.2.19 (i386).
(See commented line below.)
If rename "errno" to "errno1" - all works fine.
Is it a bug?

======== start ========
namespace mpd
{

class ErrnoException
{
public:
    ErrnoException( const char * const a,
                    const int l,
                    const int r,
                    const int e ) throw() :
        file( a ), line( l ), retval( r ), errno( e ) { }

    const char * const file;
    const int line; 
    const int retval; 
    const int errno;
};

}

#include <iostream>

using ::std::cout;
using ::std::endl;
using ::mpd::ErrnoException;


void func( const int a ) throw( ErrnoException )
{
    if( a == 2 ) throw ErrnoException( __FILE__, __LINE__, 0, 2 );
    return;
}


int main( int n, char ** a )
{
  for( int i=1; i<4; i++ )
    try
    {
        func( i );
        cout << i << endl;
    }
    catch( ErrnoException e )
    {
        cout << "Exception in file " << e.file << " at line #" << e.line <<
                ", errno = " << e.errno << "." << endl; // <-- error!
    }

    return 0;
}
======== end ========


Maxim Dementiev.

Re: GCC 3.0.2: errno conflict.

[Alexandre Oliva]

On Dec 14, 2001, "Maxim Dementiev" <max@e-soft.ru> wrote:

> Excuse me if this bug is wellknown for peaple.

It's not a bug.

> This code copile with error by g++ 3.0.2 on Linux 2.2.19 (i386).
> (See commented line below.)
> If rename "errno" to "errno1" - all works fine.
> Is it a bug?

Not really.  If it's a bug somewhere, it's in the C library you're
using.  But I'm pretty sure errno is allowed to be defined as a macro,
since that's the only reasonable way to get per-thread errno
variables in multi-threaded programs.


-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: GCC 3.0.2: errno conflict.

[Joe Buck]

> On Dec 14, 2001, "Maxim Dementiev" <max@e-soft.ru> wrote:
> 
> > Excuse me if this bug is wellknown for peaple.

Alexandre Oliva wrote:
> It's not a bug.

Well, I'm not certain about that ... I think that it is a bug, though
as you say, not in the compiler.

> > This code copile with error by g++ 3.0.2 on Linux 2.2.19 (i386).
> > (See commented line below.)
> > If rename "errno" to "errno1" - all works fine.
> > Is it a bug?
> 
> Not really.  If it's a bug somewhere, it's in the C library you're
> using.  But I'm pretty sure errno is allowed to be defined as a macro,
> since that's the only reasonable way to get per-thread errno
> variables in multi-threaded programs.

Right, errno is allowed to be a macro, but the code in question does not
have an #include of <errno.h> or of <cerrno>.  Presumably the header is
indirectly included by some other header.  Is errno still in effect a
reserved word in this circumstance?  Any standards gurus?

Re: GCC 3.0.2: errno conflict.

[Alexandre Oliva]

On Dec 14, 2001, Joe Buck <jbuck@synopsys.COM> wrote:

> Right, errno is allowed to be a macro, but the code in question does not
> have an #include of <errno.h> or of <cerrno>.

Good point.  I had failed to consider this possibility.  It does
indicate a bug in the library, then.  But it may be a bug in libstdc++
or in glibc.  It appears that it shouldn't be leaking into the user
space before <cerrno> or <errno.h> are included.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: GCC 3.0.2: errno conflict.

[Joe Buck]

[ this discussion was on gcc, I'm adding libstdc++ ]

Maxim Dementiev writes:

> Excuse me if this bug is wellknown for peaple.
> This code copile with error by g++ 3.0.2 on Linux 2.2.19 (i386).
> (See commented line below.)
> If rename "errno" to "errno1" - all works fine.
> Is it a bug?

[ testcase uses errno as an identifier, and there is a collision with
the errno macro in glibc, but the only #include was for <iostream> ]

I think that the conclusion is that, since you did not include <errno.h>
or <cerrno> explicitly, there is a bug.  errno is allowed to be a macro,
but only if you ask for one of these headers, which you did not.
(Nevertheless some user of your class may want to use the system errno in
the same file as the class you define, so you may want to avoid the use of
the errno identifier anyway).

I think that the problem is in libstdc++, in locale_facets.tcc.
locale_facets.tcc's do_get templates clear and then test errno.
So this is a libstdc++ bug.

It seems that an easy fix would be to remember if errno is defined
as a macro or not at the beginning of the header, then test again
at the end.  If it becomes defined, undefine it.  Something like

... at the beginning of locale_facets.tcc:

#ifndef errno
#define __errno_was_not_defined
#endif

... at the end of locale_facets.tcc:

#if defined(errno) && defined(__errno_was_not_defined)
#undef errno
#undef __errno_was_not_defined
#endif

Re: GCC 3.0.2: errno conflict.

[Nathan Myers]

On Fri, Dec 14, 2001 at 03:51:09PM -0800, Joe Buck wrote:
> Maxim Dementiev writes:
> > This code compile with error by g++ 3.0.2 on Linux 2.2.19 (i386).
> > If rename "errno" to "errno1" - all works fine.
> > Is it a bug?
> 
> [ testcase uses errno as an identifier, and there is a collision with
> the errno macro in glibc, but the only #include was for <iostream> ]
> 
> I think that the conclusion is that, since you did not include <errno.h>
> or <cerrno> explicitly, there is a bug.  errno is allowed to be a macro,
> but only if you ask for one of these headers, which you did not.

In C++, errno is required to be a macro.  Further, it is a reserved name
if _any_ standard C++ header is included.  

Any code that includes a standard header and tries to use errno in any 
way incompatible with its role in the C library is wrong.

In general, any C library name that may need to be implemented as a
macro (errno, va_*, offsetof) is required to be a macro in C++; all 
the others are required not to be macros (although that is violated 
in current libstdc++).  Further, including any C++ header causes all 
C library names (excluding new C99 names) to be reserved: the non-macro 
names in global scope, and the macro names in all scopes.

Nathan Myers
ncm at cantrip dot org

Re: GCC 3.0.2: errno conflict.

[Alexandre Oliva]

On Dec 14, 2001, Nathan Myers <ncm-nospam@cantrip.org> wrote:

> In C++, errno [...] is a reserved name
> if _any_ standard C++ header is included.  

Reference?  I couldn't find it in a quick search :-(

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: GCC 3.0.2: errno conflict.

[Nathan Myers]

On Fri, Dec 14, 2001 at 10:57:30PM -0200, Alexandre Oliva wrote:
> On Dec 14, 2001, Nathan Myers <ncm-nospam@cantrip.org> wrote:
> 
> > In C++, errno [...] is a reserved name
> > if _any_ standard C++ header is included.  
> 
> Reference?  I couldn't find it in a quick search :-(

[lib.res.on.headers], p. 324

  17.4.4.1 Headers

  A C++ header may include other C++ headers.

Nathan Myers
ncm at cantrip dot org

Re: GCC 3.0.2: errno conflict.

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.COM> writes:

| [ this discussion was on gcc, I'm adding libstdc++ ]
| 
| Maxim Dementiev writes:
| 
| > Excuse me if this bug is wellknown for peaple.
| > This code copile with error by g++ 3.0.2 on Linux 2.2.19 (i386).
| > (See commented line below.)
| > If rename "errno" to "errno1" - all works fine.
| > Is it a bug?
| 
| [ testcase uses errno as an identifier, and there is a collision with
| the errno macro in glibc, but the only #include was for <iostream> ]
| 
| I think that the conclusion is that, since you did not include <errno.h>
| or <cerrno> explicitly, there is a bug.

No, the C++ standard explicitly grants right to standard headers
(except those inherited from C and the <cxxx> variants) to #include
any other header.  A well wriitten C++ program  should not make any
assumption about which header #includes which.  From that point of
view, I would say the testcase is ill-designed.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: GCC 3.0.2: errno conflict.

[Joe Buck]

> | I think that the conclusion is that, since you did not include <errno.h>
> | or <cerrno> explicitly, there is a bug.
> 
> No, the C++ standard explicitly grants right to standard headers
> (except those inherited from C and the <cxxx> variants) to #include
> any other header.  A well wriitten C++ program  should not make any
> assumption about which header #includes which.  From that point of
> view, I would say the testcase is ill-designed.

Are you saying, then, that "errno" is a reserved identifier in C++ for all
programs that include any standard headers?  I am skeptical of this
argument.  I suspect that the intent of the language you refer to was to
allow standard functions and classes to wind up defined.

For one thing, it would mean that all C functions are in the global
namespace, since, by your argument, any system header can include any
other header, including the old C headers.

But perhaps we can ask the folks at comp.std.c++ what they think.

Re: GCC 3.0.2: errno conflict.

[Benjamin Kosnik]

> For one thing, it would mean that all C functions are in the global
> namespace, since, by your argument, any system header can include any
> other header, including the old C headers.

We are talking about a macro here, first of all. Not a function.

Second of all, C++ headers are cerrno, and things like cstdarg, which 
explicitly put into namespace std::. The C compatibilty headers are things like 
stdarg.h, that inject the std names into the global namespace.

I consider this issue resolved.

-benjamin

Re: GCC 3.0.2: errno conflict.

[Nathan Myers]

On Sat, Dec 15, 2001 at 07:45:54PM -0800, Joe Buck wrote:
> 
> > | I think that the conclusion is that, since you did not include
> > | <errno.h> or <cerrno> explicitly, there is a bug.
> > 
> > No, the C++ standard explicitly grants right to standard headers
> > (except those inherited from C and the <cxxx> variants) to #include
> > any other header.  A well wriitten C++ program  should not make any
> > assumption about which header #includes which.  From that point of
> > view, I would say the testcase is ill-designed.
> 
> Are you saying, then, that "errno" is a reserved identifier in C++ for
> all programs that include any standard headers?  I am skeptical of this
> argument.  I suspect that the intent of the language you refer to was
> to  allow standard functions and classes to wind up defined.

The standard doesn't address linkage names, declared or not.
In C++ (unlike C) an undeclared function cannot be called at all.
 
> For one thing, it would mean that all C functions are in the global
> namespace, since, by your argument, any system header can include any
> other header, including the old C headers.

The C functions are not allowed to be implemented as macros in C++.
(They are allowed to be inline functions.)  The list of lower-case
names that may be macros -- and must be, there is no ambiguity on 
that point in C++ -- is very short.  (Of course there are lots of 
upper-case names that are macros.)

Some people argue that the C names *should* be treated as visible in 
global scope, because they are certainly available for linkage.  All 
agree that it doesn't say that now.

The specified relationship between the <c...> and the <...h> headers 
rules out the former including the latter.
 
> But perhaps we can ask the folks at comp.std.c++ what they think.

This has come up in committee several times before, in various guises.
The official resolution is always the same, once it is recognized.

Nathan Myers
ncm at cantrip dot org

Re: GCC 3.0.2: errno conflict.

[Gabriel Dos Reis]

Joe Buck <jbuck@synopsys.COM> writes:

| > | I think that the conclusion is that, since you did not include <errno.h>
| > | or <cerrno> explicitly, there is a bug.
| > 
| > No, the C++ standard explicitly grants right to standard headers
| > (except those inherited from C and the <cxxx> variants) to #include
| > any other header.  A well wriitten C++ program  should not make any
| > assumption about which header #includes which.  From that point of
| > view, I would say the testcase is ill-designed.
| 
| Are you saying, then, that "errno" is a reserved identifier in C++ for all
| programs that include any standard headers?

any standard headers except those inherited from C and their <cxxx>
variants.  The Standard is clear about that.  Quote has been provided
elsewhere in this thread.

| I am skeptical of this argument.

Trust it or not but that is not my invention :-)

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: GCC 3.0.2: errno conflict.

[Benjamin Kosnik]

> With a good precompiled header scheme ....

I dream of this day. The C++ standard library clearly assumes something 
like this. I wish this was an option for g++.

-benjamin

Re: GCC 3.0.2: errno conflict.

[mike stump]

> To: mike stump <mrs@windriver.com>
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 14 Dec 2001 23:51:30 -0200

> Is this supposed to be read as *any* other headers?

Yes.  For example, older wording said:

2    None of the C headers includes any of the other headers,  except  that
  each  C  header  includes  its  corresponding C++ header, as described
  above.  None of the C++ headers includes any of the C  headers.   How-
  ever, any of the C++ headers can include any of the other C++ headers,
  and must include a C++ header that contains any needed definition.99)

  99) Including any one of the C++ headers can introduce all of the  C++
  headers  into a translation unit, or just the one that is named in the
  #include preprocessing directive.

As you can see, the idea and semantic history can clearly be seen.

> What's the point of defining separate headers and what each one
> should include, then?

Just in case the implementation doesn't offer performance when all
headers are included.  Some C++ systems still do that, like ours.

With a good precompiled header scheme, and because everything is in
std, it seems reasonable to just have all std things visible, all the
time.  The rule was put in at least in part to allow for a single
precompiled header that did the entire std library in one shot with no
subdivision.  In fact, we used to have the header <all>:

4 The header <all> includes all the other C++ headers.

But, for some reason, I can't find it anymore.  Hum, I'll have to go
digging to find out why it didn't last.  It seems like a good idea.

Re: GCC 3.0.2: errno conflict.

[Nathan Myers]

On Fri, Dec 14, 2001 at 11:51:30PM -0200, Alexandre Oliva wrote:
> >   17.4.4.1  Headers                                 [lib.res.on.headers]
> 
> > 1 A C++ header may include other C++ headers.161)                         |
> 
> Is this supposed to be read as *any* other headers?  

Only other standard headers.

> What's the point
> of defining separate headers and what each one should include, then?

(Other people have asked that, and proposed a <std> header that gets
everything.  Of course you can write your own, if you want.)

The list of what the header contains tells you what you are
guaranteed to get.  You might get other stuff defined in other 
headers, too.  ("NOW how much would you pay?")

Nathan Myers
ncm at cantrip dot org

Re: GCC 3.0.2: errno conflict.

[Alexandre Oliva]

On Dec 14, 2001, mike stump <mrs@windriver.com> wrote:

>> To: Nathan Myers <ncm-nospam@cantrip.org>
>> Cc: libstdc++@gcc.gnu.org, gcc@gcc.gnu.org
>> From: Alexandre Oliva <aoliva@redhat.com>
>> Date: 14 Dec 2001 22:57:30 -0200

>> On Dec 14, 2001, Nathan Myers <ncm-nospam@cantrip.org> wrote:

>> > In C++, errno [...] is a reserved name
>> > if _any_ standard C++ header is included.  

>> Reference?  I couldn't find it in a quick search :-(

> This is a homework problem... :-)

Indeed.  Thanks :-)

>   17.3.4.1  Headers                                 [lib.res.on.headers]

> 1 A C++ header may include other C++ headers.161)                         |

Is this supposed to be read as *any* other headers?  What's the point
of defining separate headers and what each one should include, then?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: GCC 3.0.2: errno conflict.

[mike stump]

> To: Nathan Myers <ncm-nospam@cantrip.org>
> Cc: libstdc++@gcc.gnu.org, gcc@gcc.gnu.org
> From: Alexandre Oliva <aoliva@redhat.com>
> Date: 14 Dec 2001 22:57:30 -0200

> On Dec 14, 2001, Nathan Myers <ncm-nospam@cantrip.org> wrote:

> > In C++, errno [...] is a reserved name
> > if _any_ standard C++ header is included.  

> Reference?  I couldn't find it in a quick search :-(

This is a homework problem... :-)

  17.3.4.1  Headers                                 [lib.res.on.headers]

1 A C++ header may include other C++ headers.161)                         |

  161) C++ headers must include a C++ header that  contains  any  needed
  definition (3.2).