#563612 strchr(3): wrong return type for strchr

#563612#5
Date:
2010-01-04 03:27:31 UTC
From:
To:
Manpage reports a return type of "char*", but string.h from libc6-dev
(eglibc 2.10.2-2) uses "const char*".

#563612#12
Date:
2010-01-05 16:01:53 UTC
From:
To:
Upstream maintainer here... POSIX/SUS says that the return type is
"char *". I'm reluctant to make any change that makes a tighter
specification than POSIX. But, reading the glibc headers, the
situation isn't 100% clear to me. Can you quote the lines you think
indicate that the return type is "const char *" (bearing in mind that
there are varios conditionals that select among several declarations
of strchr())?

Thanks,

Michael

#563612#17
Date:
2010-01-06 03:03:18 UTC
From:
To:
Hi,

First of all, I omitted one point in my initial description: I
am compiling C++ code (fixing #560454).

OK.

Right.  In fact, for C code, the glibc header agrees with the manpage
"char* strchr( const char*, int)" so I was wrong in my initial
characterization of the bug.

Since I'm writing C++ code, the relevant part of string.h is:

#ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
extern "C++"
{
extern char *strchr (char *__s, int __c)
     __THROW __asm ("strchr") __attribute_pure__ __nonnull ((1));
extern __const char *strchr (__const char *__s, int __c)
     __THROW __asm ("strchr") __attribute_pure__ __nonnull ((1));
...


Thus in C++, there is a second overload of the method:

            char* strchr(      char*, int)
AND   const char* strchr(const char*, int)


I'm not sure where you put this kind of C++ variation in the
manpages.  I'll leave that for you to decide.

Regards,
-Steve

P.S.  You can see the problem compiling the following with g++:

  #include <string.h>


  int main( int argc, char* argv[] )
  {
      const char* s1 = argv[0];
      char* p = strchr( s1, '/' );

      return p == 0;
  }