Hi, First of all, I omitted one point in my initial description: I am compiling C++ code (fixing #560454).
On Wed, Jan 06, 2010 at 05:01:53AM +1300, Michael Kerrisk wrote:
> On Mon, Jan 4, 2010 at 4:27 PM, Steve M. Robbins <s...@debian.org> wrote:
> > Package: manpages-dev
> > Version: 3.23-1
> > Severity: normal
> >
> > Manpage reports a return type of "char*", but string.h from libc6-dev
> > (eglibc 2.10.2-2) uses "const char*".
>
> 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.
OK.
> 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())?
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;
}
signature.asc
Description: Digital signature
