Re: libstdc++/2767

Re: libstdc++/2767

[Benjamin Kosnik]

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

From: Benjamin Kosnik <bkoz@redhat.com>
To: Peter Schmid <schmid@snake.iap.physik.tu-darmstadt.de>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2767
Date: Tue, 29 May 2001 10:02:41 -0700 (PDT)

 there are about 3 bugs for this now, thanks. 
 
 > #include<string.h>
 > #include<cstring> 
 > using namespace std;
 > 
 > void f(const char *name)
 > {
 >     strchr(name,'/');
 > }

Re: libstdc++/2767

[Peter Schmid]

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

From: Peter Schmid <schmid@snake.iap.physik.tu-darmstadt.de>
To: bkoz@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/2767
Date: Sat, 26 May 2001 05:46:31 +0200 (CEST)

 Please close the bugreport and file a new one, if not someone else
 did, for the following code te.C. I believe this code is reasonable
 and the inclusion of both string.h and cstring.h
 happens in known programming packages, e.g. confer root. 
 
 Hope this helps,
 
 Peter Schmid
 
 Source code te.C
 
 #include<string.h>
 #include<cstring> 
 using namespace std;
 
 void f(const char *name)
 {
     strchr(name,'/');
 }
 
 g++ -v -c te.C
 Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0/specs
 Configured with: ../gcc/configure --enable-shared --disable-nls --enable-threads=posix --enable-long-long --enable-languages=c,c++,f77,objc
 Thread model: posix
 gcc version 3.0 20010525 (prerelease)
  /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0/cc1plus -v -D__GNUC__=3 -D__GNUC_MINOR__=0 -D__GNUC_PATCHLEVEL__=0 -D__ELF__ -Dunix -Dlinux -D__ELF__ -D__unix__ -D__linux__ -D__unix -D__linux -Asystem=posix -D__STDC_HOSTED__=1 -Acpu=i386 -Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i686__ -D__tune_pentiumpro__ te.C -D__GNUG__=3 -D_GNU_SOURCE -D__GXX_DEPRECATED -D__EXCEPTIONS -D__GXX_ABI_VERSION=100 -quiet -dumpbase te.C -version -o /tmp/ccvvWzyB.s
 GNU CPP version 3.0 20010525 (prerelease) (cpplib) (i386 Linux/ELF)
 GNU C++ version 3.0 20010525 (prerelease) (i686-pc-linux-gnu)
 	compiled by GNU C version 3.0 20010525 (prerelease).
 #include "..." search starts here:
 #include <...> search starts here:
  /usr/local/include/g++-v3
  /usr/local/include/g++-v3/i686-pc-linux-gnu
  /usr/local/include/g++-v3/backward
  /usr/local/include
  /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.0/include
  /usr/local/i686-pc-linux-gnu/include
  /usr/include
 End of search list.
 te.C: In function `void f(const char*)':
 te.C:7: call of overloaded `strchr(const char*&, char)' is ambiguous
 /usr/include/string.h:155: candidates are: char* strchr(const char*, int)
 /usr/local/include/g++-v3/bits/std_cstring.h:147:                 char* 
    std::strchr(char*, int) <near match>
 /usr/local/include/g++-v3/bits/std_cstring.h:143:                 const char* 
    std::strchr(const char*, int)
 
 

Re: libstdc++/2767

[bkoz]

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

From: bkoz@gcc.gnu.org
To: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org,
  schmid@snake.iap.physik.tu-darmstadt.de
Cc:  
Subject: Re: libstdc++/2767
Date: 25 May 2001 04:48:01 -0000

 Synopsis: Problems with the new bits/std_cstring.h header
 
 State-Changed-From-To: analyzed->feedback
 State-Changed-By: bkoz
 State-Changed-When: Thu May 24 21:48:01 2001
 State-Changed-Why:
     Hey Peter, this specific symptom has been fixed, but as you are probably aware, the current c_std headers are wrong. This problem will really only be fixed when c_shadow headers are working.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2767&database=gcc

Re: libstdc++/2767

[Benjamin Kosnik]

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

From: Benjamin Kosnik <bkoz@redhat.com>
To: Peter Schmid <schmid@snake.iap.physik.tu-darmstadt.de>
Cc: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, stephen@bregmasoft.com
Subject: Re: libstdc++/2767
Date: Tue, 8 May 2001 19:35:45 -0700 (PDT)

 please check out current CVS for include/c_std/bits/std_cstring.h
 
 > "Functions for manipulating C-style strings are found in <string.h>
 > and <cstring>:
 > ...
 > const char* strchr(const char*, int);
 > char* strchr(char*, int);"
 
 right...
 
 > On the following page he mentions the "C standard library definition,
 > not C++" of strchr:
 > 
 > char* strchr(cont char*, int);
 
 right....
 
 > Therefore, I believe, the prototypes in the current libstdc++
 > implementation for strchr are indeed correct. 
 
 the prototypes signatures were correct, as above. However, they referred to
 the "C" version as having the following signature, which was incorrect:
 
 extern "C" const char* strchr(cont char*, int);
            ^^^^^
 
 This has been fixed.
 
 
 In the short term, you'll need to explicitly qualify these functions with 
 std:: to remove ambiguity. In the long term, somebody should try to clean 
 up the shadow header implementation.
 
 best,
 benjamin

Re: libstdc++/2767

[Peter Schmid]

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

From: Peter Schmid <schmid@snake.iap.physik.tu-darmstadt.de>
To: bkoz@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org, stephen@bregmasoft.com
Subject: Re: libstdc++/2767
Date: Wed, 9 May 2001 03:09:22 +0200 (CEST)

 |Regardless, the current implementation is incorrect, as this declaration doesn't exist:
 |      extern "C" const char* strchr(const char*, int); 
 |     should be
 |      extern "C" char* strchr(const char*, int); 
  
 I am puzzled. Stroustrup says in his book "The C++ programming
 language" (special edition) on page 599:
 
 "Functions for manipulating C-style strings are found in <string.h>
 and <cstring>:
 ...
 const char* strchr(const char*, int);
 char* strchr(char*, int);"
 
 On the following page he mentions the "C standard library definition,
 not C++" of strchr:
 
 char* strchr(cont char*, int);
 
 This is the same as stated in the book "C, a refrence manual by
 Harbison and Steele. 
 
 Therefore, I believe, the prototypes in the current libstdc++
 implementation for strchr are indeed correct. 
 
 One has to cope with the different signatures for the C and the C++
 versions of the function strchr (among others). 
 
 Hope this is correct,
 
 Peter Schmid
 
 

Re: libstdc++/2767

[bkoz]

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

From: bkoz@gcc.gnu.org
To: bkoz@gcc.gnu.org, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org,
  schmid@snake.iap.physik.tu-darmstadt.de, stephen@bregmasoft.com
Cc:  
Subject: Re: libstdc++/2767
Date: 8 May 2001 22:45:34 -0000

 Synopsis: Problems with the new bits/std_cstring.h header
 
 Responsible-Changed-From-To: unassigned->bkoz
 Responsible-Changed-By: bkoz
 Responsible-Changed-When: Tue May  8 15:45:34 2001
 Responsible-Changed-Why:
     Responsible
 State-Changed-From-To: open->analyzed
 State-Changed-By: bkoz
 State-Changed-When: Tue May  8 15:45:34 2001
 State-Changed-Why:
     Ugh. This can't be fixed without moving to the shadow headers:
     
     
     namespace swamp
     {
       extern "C"
       {
         extern char*
         strchr(const char *__s, int __c);
       }
     }
     
     namespace std
     {
       const char*
       strchr(const char* __s1, int __n)
       { return const_cast<const char*>(swamp::strchr(__s1, __n)); }
     
       char*
       strchr(char* __s1, int __n)
       { return swamp::strchr(const_cast<const char*>(__s1), __n); }
     }
     
     void f(const char* name)
     { 
       using namespace std;
       strchr(name, int('/')); 
     }
     
     This works, as long as you compile with -fno-builtin. 
     
     Regardless, the current implementation is incorrect, as this declaration doesn't exist:
      extern "C" const char* strchr(const char*, int); 
     
     should be
     
      extern "C" char* strchr(const char*, int); 
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2767&database=gcc