Re: libstdc++/3026

Re: libstdc++/3026

[Giacomo Catenazzi]

The following reply was made to PR libstdc++/3026; it has been noted by GNATS.

From: Giacomo Catenazzi <cate@math.ethz.ch>
To: pme@gcc.gnu.org
Cc: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: Wed, 06 Jun 2001 17:32:27 +0200

 pme@gcc.gnu.org wrote:
 > 
 >     Egads.  A bunch of problems conspiring together.
 > 
 >     On one hand, the c_std headers are being used, which are
 >     known to be nonconforming in this respect.  Replacing the
 >     installed std_cstddef.h with the one from c_shadow solves
 >     the initial 'size_t/ptrdiff_t not declared' problem.
 > 
 >     On the other hand, /usr/include/stdlib.h starts giving
 >     parse errors due to its lack of knowledge about namespace
 >     std and namespaces in general; unqualified use of 'size_t'
 >     breaks in this case.
 > 
 
 Ok, but there is also the main problem:
 why not to change also ::acosl into std::acosl (and this change
 for few other math functions) ?
 
 This should correct the error:
  /usr/local/include/g++-v3/bits/std_cmath.h: In function `long double 
                   foo::std::acos(long double)':
                   /usr/local/include/g++-v3/bits/std_cmath.h:121: `::acosl'
 	          undeclared (first use here)
 
 
 	giacomo

Re: libstdc++/3026

[Gabriel Dos Reis]

The following reply was made to PR libstdc++/3026; it has been noted by GNATS.

From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: "Catenazzi, Giacomo Amabile" <giacomoamabile.catenazzi@cepe.mavt.ethz.ch>
Cc: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>, cate@dplanet.ch,
   gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: 07 Jun 2001 18:23:31 +0200

 "Catenazzi, Giacomo Amabile" <giacomoamabile.catenazzi@cepe.mavt.ethz.ch> writes:
 
 | Gabriel Dos Reis wrote:
 | > 
 | > Giacomo Catenazzi <cate@math.ethz.ch> writes:
 | > 
 | > | Gabriel Dos Reis wrote:
 | > |
 | > | An other problem: Should '#include <complex>' define functions/classes
 | > | in std namespace, without exporting it in global namespace?
 | > | Now <complex> and <complex.h> are the same, and both use global
 | > | namespace.
 | > 
 | > There is nothing named <complex.h> specified by C++.  The standard
 | > header <complex> defines its entities only in namespace std.  I
 | > strongly suggest you stick to those standard interfaces.
 | > 
 | 
 | Ok. Sorry. Confused about different version of library.
 | BTW
 | .  #include <complex>
 | .  int foo(std::complex<double> z) {
 | .    return int(real(z));
 | .  }
 | This code will compile on http://www.codesourcery.com/gcc-compile.shtml
 | thus 'real' is in also on global namespace.
 
 No, the conclusion doesn't follow. `real' is in the standard namespace.
 It is found thanks to Koenig lookup.
 
 -- Gaby

Re: libstdc++/3026

[Catenazzi, Giacomo Amabile]

The following reply was made to PR libstdc++/3026; it has been noted by GNATS.

From: "Catenazzi, Giacomo Amabile"
	 <giacomoamabile.catenazzi@cepe.mavt.ethz.ch>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
Cc: cate@dplanet.ch, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: Thu, 07 Jun 2001 17:17:08 +0200

 Gabriel Dos Reis wrote:
 > 
 > Giacomo Catenazzi <cate@math.ethz.ch> writes:
 > 
 > | Gabriel Dos Reis wrote:
 > |
 > | An other problem: Should '#include <complex>' define functions/classes
 > | in std namespace, without exporting it in global namespace?
 > | Now <complex> and <complex.h> are the same, and both use global
 > | namespace.
 > 
 > There is nothing named <complex.h> specified by C++.  The standard
 > header <complex> defines its entities only in namespace std.  I
 > strongly suggest you stick to those standard interfaces.
 > 
 
 Ok. Sorry. Confused about different version of library.
 BTW
 .  #include <complex>
 .  int foo(std::complex<double> z) {
 .    return int(real(z));
 .  }
 This code will compile on http://www.codesourcery.com/gcc-compile.shtml
 thus 'real' is in also on global namespace.
 [But I'm not sure about the standard: the functions/classes should be in
 std namespace, but they can be exported implicitly in the global
 namespace?]
 
 	giacomo

Re: libstdc++/3026

[Gabriel Dos Reis]

The following reply was made to PR libstdc++/3026; it has been noted by GNATS.

From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: cate@dplanet.ch
Cc: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>, pme@gcc.gnu.org,
   gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: 07 Jun 2001 14:44:41 +0200

 Giacomo Catenazzi <cate@math.ethz.ch> writes:
 
 | Gabriel Dos Reis wrote:
 | > 
 | > Giacomo Catenazzi <cate@math.ethz.ch> writes:
 | > | 
 | > |  Ok, but there is also the main problem:
 | > |  why not to change also ::acosl into std::acosl (and this change
 | > |  for few other math functions) ?
 | > 
 | > Ideally we should be doing something to that effect.  But the details
 | > and issues aren't tht crystal clear -- trust me, we're working on
 | > fixes.
 | > 
 | > -- Gaby
 | 
 | An other problem: Should '#include <complex>' define functions/classes
 | in std namespace, without exporting it in global namespace?
 | Now <complex> and <complex.h> are the same, and both use global
 | namespace.
 
 There is nothing named <complex.h> specified by C++.  The standard
 header <complex> defines its entities only in namespace std.  I
 strongly suggest you stick to those standard interfaces.
 
 -- Gaby
 CodeSourcery, LLC                       http://www.codesourcery.com

Re: libstdc++/3026

[Giacomo Catenazzi]

The following reply was made to PR libstdc++/3026; it has been noted by GNATS.

From: Giacomo Catenazzi <cate@math.ethz.ch>
To: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
Cc: pme@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: Thu, 07 Jun 2001 09:52:14 +0200

 Gabriel Dos Reis wrote:
 > 
 > Giacomo Catenazzi <cate@math.ethz.ch> writes:
 > | 
 > |  Ok, but there is also the main problem:
 > |  why not to change also ::acosl into std::acosl (and this change
 > |  for few other math functions) ?
 > 
 > Ideally we should be doing something to that effect.  But the details
 > and issues aren't tht crystal clear -- trust me, we're working on
 > fixes.
 > 
 > -- Gaby
 
 An other problem: Should '#include <complex>' define functions/classes
 in std namespace, without exporting it in global namespace?
 Now <complex> and <complex.h> are the same, and both use global
 namespace.
 
 [
 My problem:
 I works on a huge numeric library. It define 'real' as normal float type.
 Now I should add templates to support complex numbers.
 But complex.h uses 'real' as function (to return the real part of a
 complex number).
 Nesting the header file in a 'foo' namespace was the workaround for
 gcc 2.9x. (with an addithin: using ::istream and ostream).
 In pre 3.0 it doesn't works, thus this bug report.
 Now I'm searching a manner to split the global (library namespace)
 with the complex namespace. (The library is too huge to rename
 the library 'real' type).
 ]
 
 If you define the whole complex library in std namespace, I think
 the problem is solved. (but some bad preprocessors macros for
 worksaround in gcc 2.9x).
 
 	giacomo

Re: libstdc++/3026

[Gabriel Dos Reis]

The following reply was made to PR libstdc++/3026; it has been noted by GNATS.

From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: Giacomo Catenazzi <cate@math.ethz.ch>
Cc: pme@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: 06 Jun 2001 20:06:12 +0200

 Giacomo Catenazzi <cate@math.ethz.ch> writes:
 
 | The following reply was made to PR libstdc++/3026; it has been noted by GNATS.
 | 
 | From: Giacomo Catenazzi <cate@math.ethz.ch>
 | To: pme@gcc.gnu.org
 | Cc: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org
 | Subject: Re: libstdc++/3026
 | Date: Wed, 06 Jun 2001 17:32:27 +0200
 | 
 |  pme@gcc.gnu.org wrote:
 |  > 
 |  >     Egads.  A bunch of problems conspiring together.
 |  > 
 |  >     On one hand, the c_std headers are being used, which are
 |  >     known to be nonconforming in this respect.  Replacing the
 |  >     installed std_cstddef.h with the one from c_shadow solves
 |  >     the initial 'size_t/ptrdiff_t not declared' problem.
 |  > 
 |  >     On the other hand, /usr/include/stdlib.h starts giving
 |  >     parse errors due to its lack of knowledge about namespace
 |  >     std and namespaces in general; unqualified use of 'size_t'
 |  >     breaks in this case.
 |  > 
 |  
 |  Ok, but there is also the main problem:
 |  why not to change also ::acosl into std::acosl (and this change
 |  for few other math functions) ?
 
 Ideally we should be doing something to that effect.  But the details
 and issues aren't tht crystal clear -- trust me, we're working on
 fixes.
 
 -- Gaby

Re: libstdc++/3026

[Gabriel Dos Reis]

The following reply was made to PR libstdc++/3026; it has been noted by GNATS.

From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: pme@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: 05 Jun 2001 19:52:28 +0200

 pme@gcc.gnu.org writes:
 
 |      Gripping hand, I'm not entirely certain that
 |      
 |          namespace foo {
 |              #include <something_standard.h>
 |          }
 
 Such constructs lead to undefined behaviour.  Period.  Nobody should
 be writing something like that unless he/she knows what he/she is
 doing. 
 
 -- Gaby

Re: libstdc++/3026

[Benjamin Kosnik]

The following reply was made to PR libstdc++/3026; it has been noted by GNATS.

From: Benjamin Kosnik <bkoz@redhat.com>
To: pme@gcc.gnu.org
Cc: cate@debian.org, gcc-gnats@gcc.gnu.org, pme@gcc.gnu.org
Subject: Re: libstdc++/3026
Date: Tue, 5 Jun 2001 09:53:05 -0700 (PDT)

 thanks for looking at this phil.
 
 >     is permitted in userland by [17.4.1.1]/2, "All library
 >     entities ... are defined within the namespace std or
 >     namespaces nested within namespace std."  Here we're
 >     nesting namespace std inside another namespace.
 
 good point.
 
 >     If this code is valid, then I think this becomes another
 >     "funky C wrapping header problem" PR.
 
 I think you are right, and that this code is not allowed.
 
 Thoughts?
 
 -benjamin

Re: libstdc++/3026

[pme]

The following reply was made to PR libstdc++/3026; it has been noted by GNATS.

From: pme@gcc.gnu.org
To: bkoz@gcc.gnu.org, cate@debian.org, gcc-gnats@gcc.gnu.org, pme@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/3026
Date: 5 Jun 2001 16:35:36 -0000

 Synopsis: namespace errors in <complext.h> and other .h
 
 State-Changed-From-To: open->analyzed
 State-Changed-By: pme
 State-Changed-When: Tue Jun  5 09:35:36 2001
 State-Changed-Why:
     
     Egads.  A bunch of problems conspiring together.
     
     On one hand, the c_std headers are being used, which are
     known to be nonconforming in this respect.  Replacing the
     installed std_cstddef.h with the one from c_shadow solves
     the initial 'size_t/ptrdiff_t not declared' problem.
     
     On the other hand, /usr/include/stdlib.h starts giving
     parse errors due to its lack of knowledge about namespace
     std and namespaces in general; unqualified use of 'size_t'
     breaks in this case.
     
     Gripping hand, I'm not entirely certain that
     
         namespace foo {
             #include <something_standard.h>
         }
     
     is permitted in userland by [17.4.1.1]/2, "All library
     entities ... are defined within the namespace std or
     namespaces nested within namespace std."  Here we're
     nesting namespace std inside another namespace.
     
     If this code is valid, then I think this becomes another
     "funky C wrapping header problem" PR.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3026&database=gcc

Re: libstdc++/3026

[bkoz]

The following reply was made to PR libstdc++/3026; it has been noted by GNATS.

From: bkoz@gcc.gnu.org
To: cate@debian.org, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org,
  pme@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/3026
Date: 4 Jun 2001 17:59:58 -0000

 Synopsis: namespace errors in <complext.h> and other .h
 
 Responsible-Changed-From-To: unassigned->pme
 Responsible-Changed-By: bkoz
 Responsible-Changed-When: Mon Jun  4 10:59:58 2001
 Responsible-Changed-Why:
     Perhaps you could look at this one? 
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=3026&database=gcc