Re: long long vs long

[johne@sd.com (John Estabrook)]

It would have caused a lot of grief for people who have a lot of 
code to maintain...  all the sudden a long is not 4 bytes, and a 
long isn't the same size as a pointer.  

Just recompiling your applications could render your old data files 
unreadable because people do things like read in sizeof(long) bytes.
When the files were written a long was 32 bits, if a long was changed 
to 64 then it wouldn't work.

They are tackling the 64-bit long in 64-bit compilers for 64-bit OS's.
If for whatever reason you feel the need to port an app from a 
32-bit compiler to a 64-bit compiler then you have to go back and 
work on your code to remove trouble spots.

As an aside, look at the kind of trouble people run into by C++ 
defining a bool as an integer, and C not having a bool.   Many times 
a bool was typedef'd as a char in old C code.  Now you can get 
situations where a structure containing a bool has a different size 
in C than in C++.  There's so much legacy code out there that you 
really have to be careful when messing with the old order of things.

There are links that discusses these issues if you are interested:

http://www.rdg.opengroup.org/public/tech/aspen/lp64_wp.htm
http://www.sun.com/software/events/presentations/SPG3.Goyal/SPG3.Goyal.html
http://www.unix-systems.org/version2/whatsnew/datasize.html


> Graham Murray said:
> > 
> > This is probably a silly question, but rather than having long long for
> > 64 bit, why was long not made 64bit? The standard (AFAIK) states that
> > short <= int <= long.  So, it should be possible for long to be 64 bit
> > rather than 32. This would give a simple progression from 8bit chars to
> > 64bit longs.
> 

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".