🚀 go-pugleaf

GCC 2.4.5 has decided that strlen returns an unsigned long -- for no
apparent reason, and in conflict with (at least) the SunOS 4.1.3
libc.  I just searched out the various definitions of SIZE_TYPE in the
GCC sources and fixed them to be "int". 

Fixing this GCC bug allowed ibuild to make for me, but I gave up on doc.

-- 

======================================================================8--<

In article <CA146p.21v@scr.siemens.com>
aad@scr.siemens.com (Anthony A. Datri) writes:
|> 
|> GCC 2.4.5 has decided that strlen returns an unsigned long -- for no
|> apparent reason, and in conflict with (at least) the SunOS 4.1.3
|> libc.  I just searched out the various definitions of SIZE_TYPE in the
|> GCC sources and fixed them to be "int". 
|> 
|> Fixing this GCC bug allowed ibuild to make for me, but I gave up on doc.

The bug is apparently in the Sun header files which should set size_t
to unsigned long, not int. libg++-2.4 fixes this problem.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

>The bug is apparently in the Sun header files which should set size_t
>to unsigned long, not int. libg++-2.4 fixes this problem.

Like I just said, IT DOESN'T.  In fact, String.cc contains

	inline static int slen(const char* t) // inline  strlen
	{
	  if (t == 0)
	    return 0;
	  else
	  {
	    const char* a = t;
	    while (*a++ != 0);
	    return a - 1 - t;
	  }
	}

Now, it's difficult to know if this is ever actually used as strlen, but
it sure looks to me like it says "int".

Wouldn't it be silly of Sun to have their headers say unsigned long when their
library function still returns an int?

-- 

======================================================================8--<

aad@scr.siemens.com (Anthony A. Datri) writes:

>>The bug is apparently in the Sun header files which should set size_t
>>to unsigned long, not int. libg++-2.4 fixes this problem.

>Like I just said, IT DOESN'T.  In fact, String.cc contains

>	inline static int slen(const char* t) // inline  strlen
>	{
>	  if (t == 0)
>	    return 0;
>	  else
>	  {
>	    const char* a = t;
>	    while (*a++ != 0);
>	    return a - 1 - t;
>	  }
>	}

>Now, it's difficult to know if this is ever actually used as strlen, but
>it sure looks to me like it says "int".

  It does. libg++-2.4 fixes the problem. slen is not strlen, strlen is
a Sun libc call and slen is only a inline used in String.cc.

  The problem you mentioned about gcc and interview is becuase you
have the wrong libg++. I also encountered this problem which was
caused by gcc-2.3.3 compiled libg++-2.4. I recompile libg++-2.4 with 2.4.5
and then compile interviews, everything works fine. I also use Sun CC
(cfront) compile interviews both of them work fine.

  The good thing about Sun CC is: it uses shared libraries.

  steve
--
stevew@helios.unl.edu  |=| \ Fender / |=| ... smoke on the water, fire in
                       |=|   \    /   |=| the sky...   Smoke on the water.
stevew@hoss.unl.edu    |=|     \/     |=|     (36 bars guitar solo)
		      Deep purple, the best

>>Like I just said, IT DOESN'T.  In fact, String.cc contains

>>Now, it's difficult to know if this is ever actually used as strlen, but
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>  It does. libg++-2.4 fixes the problem

One more time.  I ************AM************** using 2.4.

. slen is not strlen, strlen is
>a Sun libc call and slen is only a inline used in String.cc.

	<=>lovecraft<=>uname -a
	SunOS lovecraft 4.1.3 1 sun4c
	<=>lovecraft<=>grep strlen /usr/include/string.h
	extern size_t   strlen(/* const char *s */);
	<=>lovecraft<=>grep size_t /usr/include/sys/stdtypes.h 
	 * define the thingy.  This is used so that we don't have size_t in
	typedef int             size_t;         /* ??? */

The libc call is an int. I N T.

>  The problem you mentioned about gcc and interview is becuase you
>have the wrong libg++. I also encountered this problem which was
>caused by gcc-2.3.3 compiled libg++-2.4.

I don't know what kind of number system you use, but in mine 2.4 = 2.4.

-- 

======================================================================8--<

aad@scr.siemens.com (Anthony A. Datri) writes:

>>>Like I just said, IT DOESN'T.  In fact, String.cc contains

>>>Now, it's difficult to know if this is ever actually used as strlen, but
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>  It does. libg++-2.4 fixes the problem

>One more time.  I ************AM************** using 2.4.

>. slen is not strlen, strlen is
>>a Sun libc call and slen is only a inline used in String.cc.

>	<=>lovecraft<=>uname -a
>	SunOS lovecraft 4.1.3 1 sun4c
>	<=>lovecraft<=>grep strlen /usr/include/string.h
>	extern size_t   strlen(/* const char *s */);
>	<=>lovecraft<=>grep size_t /usr/include/sys/stdtypes.h 
>	 * define the thingy.  This is used so that we don't have size_t in
>	typedef int             size_t;         /* ??? */

>The libc call is an int. I N T.

>>  The problem you mentioned about gcc and interview is becuase you
>>have the wrong libg++. I also encountered this problem which was
>>caused by gcc-2.3.3 compiled libg++-2.4.

>I don't know what kind of number system you use, but in mine 2.4 = 2.4.

  OK let clear some misunderstanding:

try this:

vi test.c
#include <stdio.h>
typedef float size_t;
main()
{
   size_t a = strlen("You missed");
   int    b = strlen("You missed");
   short  c = strlen("You missed");

   printf("You missed %f %d %d %d\n", a, (unsigned long)a, b, c);
}

and cc test.c, gcc test.c

what you get is: NO complain at all. compiler doesn't care whether
size_t is a long, float or anything, as long as there is no
prototyping. 

  In
/usr/dist/gnu/lib/gcc-lib/sparc-sun-sunos4.1.3/2.4.5/include/string.h,
it prototype strlen as size_t, and if you have that include and have
int a = strlen(...) then you will have problem. If the header files
you have are not the gcc 2.4.5, you have a different typedef. Also,
there was a inconsistant using of size_t in libg++ which has been
fixed. I have install gcc-2.4.5, libg++-2.4 and IV 3.1 on
sparc-sun-sunos4.1.3 and I don't have to modified SIZE_TYPE (as what
the src said "In 2.4 it should work to delete it". Anyway, you must
have done something wrong.

  Also, gcc's notation should be right, strlen should be unsigned int,
what would it mean by a minus string lenght?

  steve
--
stevew@helios.unl.edu  |=| \ Fender / |=| ... smoke on the water, fire in
                       |=|   \    /   |=| the sky...   Smoke on the water.
stevew@hoss.unl.edu    |=|     \/     |=|     (36 bars guitar solo)
		      Deep purple, the best

aad@scr.siemens.com (Anthony A. Datri) writes:

>>>Like I just said, IT DOESN'T.  In fact, String.cc contains

>>>Now, it's difficult to know if this is ever actually used as strlen, but
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>>  It does. libg++-2.4 fixes the problem

>One more time.  I ************AM************** using 2.4.

>The libc call is an int. I N T.

>>  The problem you mentioned about gcc and interview is becuase you
>>have the wrong libg++. I also encountered this problem which was
>>caused by gcc-2.3.3 compiled libg++-2.4.

>I don't know what kind of number system you use, but in mine 2.4 = 2.4.

You must have done somthing wrong.

To become more ANSI complaint, the gcc maintainers have decided that
size_t should be unsigned, not only on platforms that have this by default,
but also on platforms that can be made to support this.

Now, on SunOS 4.x size_t is defined as (signed) int.
The libc strlen() function is defined to return a (signed) int.

Since it doesn't really matter whether strlen is called as a int returning
function or a function returning unsigned int, that is not a problem.
(It may become a problem when your strings are bigger than MAX_INT).

So, if you use ``unsigned int strlen()'' and call teh libc function it
still works.

In gcc 2.4.x the definition of size type as changed for SunOS 4.x.
It is now ``unsigned long int''.  The gcc fixed include files also
reflect this change.

When installing libg++ and includes, the type of size_t is determined.
When we installed libg++2.3 with gcc-2.3.3 everything worked.
When we installed gcc-2.4.x after that, the type of size_t changed for
gcc and the installed libg++ broke. After reconfiguring/installing
libg++2.3[.1], everything worked again. (Except that gcc-2.3.3 could
no longer compile C++ programs that include <string.h>).

To get a working gcc/libg++ instalation:
	- install gcc/g++ (with fixed includes and the _SIZE_TYPE
	  definition left as it was in the original source)
	- rebuild libg++ with the new gcc compiler.

Works for us (with gcc 2.4, not with gcc 2.3.3):

file.c:
#include <string.h>

% g++ -c -V 2.3.3 file.c
/usr/local/gnu/lib/g++-include/string.h:28: declaration of `long unsigned int  strlen (const char *)'
<built-in>:0: conflicts with built-in declaration `int  strlen (const char *)'
In file included from /usr/local/gnu/lib/g++-include/stddef.h:7, from /usr/local/gnu/lib/g++-include/memory.h:6, from /usr/local/gnu/lib/g++-include/string.h:43, from tty.c:1:
/usr/local/gnu/lib/gcc-lib/sun4/2.3.3/include/stddef.h:152: conflicting types for `_G_size_t'
/usr/local/gnu/lib/g++-include/_G_config.h:20: previous declaration of `_G_size_t'

# gcc 2.4.3:
% g++ -c file.c
%

Casper

In article <CA5x3K.5K0@scr.siemens.com> aad@scr.siemens.com (Anthony A. Datri) writes:
>>>Like I just said, IT DOESN'T.  In fact, String.cc contains
>
>>>Now, it's difficult to know if this is ever actually used as strlen, but
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>>  It does. libg++-2.4 fixes the problem
>
>One more time.  I ************AM************** using 2.4.

That doesn't mean you're using it correctly.

>>slen is not strlen, strlen is
>>a Sun libc call and slen is only a inline used in String.cc.
>
>	<=>lovecraft<=>uname -a
>	SunOS lovecraft 4.1.3 1 sun4c

	isolar:2:271 % uname -a
	SunOS isolar 4.1.3 2 sun4c

>	<=>lovecraft<=>grep strlen /usr/include/string.h
>	extern size_t   strlen(/* const char *s */);
>	<=>lovecraft<=>grep size_t /usr/include/sys/stdtypes.h 
>	 * define the thingy.  This is used so that we don't have size_t in
>	typedef int             size_t;         /* ??? */

isolar:2:272 % grep size_t /usr/include/sys/stdtypes.h \
/usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.4.5/include/sys/stdtypes.h 

/usr/include/sys/stdtypes.h: \
 * define the thingy.  This is used so that we don't have size_t in
/usr/include/sys/stdtypes.h: \
typedef     int             size_t;         /* ??? */

/usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.4.5/include/sys/stdtypes.h: \
 * define the thingy.  This is used so that we don't have size_t in
/usr/gnu/lib/gcc-lib/sparc-sun-sunos4.1/2.4.5/include/sys/stdtypes.h: \
typedef unsigned long int size_t;          /* ??? */

>The libc call is an int.  I N T.

You can call it whatever you want; that doesn't make it so.

gcc is supposed to be an ANSI compiler, remember?

As Brendan Kehoe of Cygnus explained it to me:

>You need to rebuild libg++ with CC=gcc, so it can find out the "real"
>definition of size_t (previous versions of the compiler used Sun's broken
>definition, instead of the correct ANSI definition).

In short:

- Build gcc 2.4.5.
- Once you have 2.4.5 installed, build libg++ 2.4 again; this time via
  "make CC=gcc"

Then you will get the correct prototype for "size_t" in the version of
<sys/stdtypes.h> that gcc actually uses.  

Capiche?

-- 
	- Greg Earle
	  Phone: (818) 353-8695		FAX: (818) 353-1877
	  Internet: earle@isolar.Tujunga.CA.US
	  UUCP: isolar!earle@elroy.JPL.NASA.GOV a.k.a. ...!elroy!isolar!earle