🚀 go-pugleaf

Compiling libg++ 2.2 with gcc 2.2.2, I get the following result:

-----
gcc -g  -I.. -I../../../libg++/src -I../../../libg++/src/../iostream
-I../../../libg++/src/../g++-include  -c ../../../libg++/src/AllocRing.cc 

In file included from ../../../libg++/src/std.h:26, from
../../../libg++/src/AllocRing.cc:22:

../../../libg++/src/../g++-include/string.h:28: declaration of `int  strlen
(const char *)'

<built-in>:0: conflicts with built-in declaration `long unsigned int
strlen (const char *)'
-----

Why does gcc think that strlen should return long unsigned int, rather than
int?  How does it go about deciding the return type for these built-in
functions?  I haven't been able to find the place in the make process where
this happens.

I am working on a Sequent Symmetry running Dynix.  The string.h we are
using comes, I believe, from the AT&T C++ translator v1.2, and looks like
this:


/*	@(#)string.h	1.2	*/
extern char
	*strcpy(),
	*strncpy(),
	*strcat(),
	*strncat(),
	*strchr(),
	*strrchr(),
	*strpbrk(),
	*strtok();
extern int
	strcmp(),
	strncmp(),
	strlen(),
	strspn(),
	strcspn();

Would the absence of "int" in front of "strlen()" be confusing the make
process?  The strings.h on the machine is the Sequent version, and has the
ususal-style declaration.

--
Jason Merrill
jason@jarthur.claremont.edu
-- 
Fool on a Pedestal