Shall be const char *strchr(const char * , int ); char *strchr(char * , int ); according to Standard. But we have char *strchr(char * , int ); and invalid char *strchr(const char * , int ); from string.h
You haven't said which version of gcc or which platform. With a recent GCC and recent glibc I get: extern "C++" { extern char *strchr (char *__s, int __c) throw () __asm ("strchr") __attribute__ ((__pure__)) __attribute__ ((__nonn ull__ (1))); extern __const char *strchr (__const char *__s, int __c) throw () __asm ("strchr") __attribute__ ((__pure__)) __attribute__ ((__nonn ull__ (1))); }
dup of PR 33935 - also related to PR 30928 *** This bug has been marked as a duplicate of bug 33935 ***
(In reply to comment #1) > You haven't said which version of gcc or which platform. > Actually 3.4.3 on Linux and Windows (MinGW) but in SVN trunk version (r169421) /trunk/libstdc++-v3/include/c_std/cstring I have not found any changes.
(In reply to comment #1) > With a recent GCC and recent glibc I get: > In which version of GCC can I find valid implementation?
GCC 4.1.1 - still no luck
In glibc 2.10 and later together with gcc 4.4 and later.
Ok, I'll try to upgrade my GCC version. Thanx
3.4 and 4.1 are ancient history, active release series are listed on the home page, http://gcc.gnu.org/
The libstdc++ uses glibc anyway? What about alternative implementations like hp-gcc for HP-UX?
(In reply to comment #8) > 3.4 and 4.1 are ancient history, active release series are listed on the home > page, http://gcc.gnu.org/ Yes, I know. But I have no ability to upgrade them in all installations
(In reply to comment #9) > The libstdc++ uses glibc anyway? What about alternative implementations like > hp-gcc for HP-UX? I don't know what hp-gcc is, but on non-glibc platforms the overloads aren't correct, see PR 33935 (In reply to comment #10) > (In reply to comment #8) > > 3.4 and 4.1 are ancient history, active release series are listed on the home > > page, http://gcc.gnu.org/ > > Yes, I know. But I have no ability to upgrade them in all installations I didn't say you should upgrade them, but there's no point reporting bugs against old, unmaintained versions. You could install a current release to test before reporting a bug though.
(In reply to comment #11) > I don't know what hp-gcc is, but on non-glibc platforms the overloads aren't > correct, see PR 33935 > PR 33935 is mostly about overloads in string.h. I'm not interested in them. Could you clarify what happen in following case. C-implementation don't provides overloads, only standard C prototype in string.h. Can I get standard-conformant prototypes by including cstring from libstdc++ on such platform? According to the trunk version of cstring answer is "No". Is this true?
If you don't use glibc 2.10+ as C library the answer is No indeed.
As stated at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33935#c4
The following code would work anyway: namespace std { #ifdef __CORRECT_ISO_CPP_STRING_H_PROTO using ::strchr; #else inline const char *strchr(const char *__s, int __c) { return ::strchr(__s, __c); } inline char *strchr(char *__s, int __c) { return ::strchr(__s, __c); } #endif }
Initial problem is that the following standard-conforming code is not compiled by GCC. #include<cstring> template<class Iter> void f(Iter i1, Iter i2) { } int main() { const char *st = "abc"; f(st, std::strchr(st, '\0')); } Yes, workaround is obvious: add the const_cast to the return value. But is there a way to do without it?
. *** This bug has been marked as a duplicate of bug 33935 ***
(In reply to comment #15) > The following code would work anyway: No, it would make this ambiguous: #include <cstring> using namespace std; int main() { strchr("foo", 'f'); } (In reply to comment #16) > Yes, workaround is obvious: add the const_cast to the return value. But is > there a way to do without it? Only with assistance from the C library, which is why this is a dup of PR 33935
(In reply to comment #18) > (In reply to comment #15) > > The following code would work anyway: > > No, it would make this ambiguous: > > #include <cstring> > using namespace std; > > int main() > { > strchr("foo", 'f'); > } > > > (In reply to comment #16) > > Yes, workaround is obvious: add the const_cast to the return value. But is > > there a way to do without it? > > Only with assistance from the C library, which is why this is a dup of PR 33935 Yeah. Seems like it's not possible to do if C-library implementer didn't care about this...