On Fri, Feb 13, 2004 at 03:11:10PM +1030, Brett Lymn wrote:
> On Thu, Feb 12, 2004 at 06:53:20PM -0800, Andrew Sharp wrote:
> > 
> > Well, the size of long shouldn't change.

Sheesh.  Apparently I had my brain checked at the door when I thinko'd
this.  Obviously, this behavior is compiler dependent, and the work that
I did for HP and Sun and others (many years ago, now) on making kernel
stuff 64-bit, was done with their proprietary compilers, and this is
about gcc, so, apologies to the list for this bit of nonsense.

> This is true but according to Jan Harkes there is the assumption that:
> 
> sizeof(int *) == sizeof(int)
> 
> which is definitely not true on a 64bit machine.  Apparently this
> breaks things very badly.

It's amazing how prevelant this assumption is in even small programs.

> >  Only the size of pointers and
> > how long long is implemented.  I don't know about netbsd, but virtually
> > every entity I'm aware of (Sun, HP, Linux) a long is 32 bits no matter
> > how it's compiled. 

So, I recently was browsing through the info file for gcc-3.3, and this
is completely wrong for gcc-3.3 and most likely gcc-3.x.  It explicitly
says that compiling with -m64 will make longs 64 bit.  Which will break
just about everything in sight.  I heard, but I don't know personally,
that most actual gnu software has been cleaned up wrt superfluous use of
long instead of int.

For some reason, programmers are quite fond of using the long data type,
even when they were programming for one platform in which int's and
long's were the same size.  Psychologists are having a field day.

HP and Sun and others decided to leave long's as 32 bits for exactly the
reason that the breakage would be so complete if they didn't.  Hence the
creation of the 'long long' type and the others that followed.  Perhaps
gcc should have done the same thing.  It's a debate.

> > I think that the latest versions of lint have modes that can check your
> > code for possible places they will break if compiled for 64 bit use.
> 
> That would be handy.  At the moment I am looking at just ripping out
> casts and seeing what falls over - fixing the lossage as I go.

Brave man, indeed.

a