On Thu, 5 Sep 2002, Hartvig Ekner wrote: > I don't know the ultimate reasons why SGI choose ILP32 for n32, but one > could certainly be portability. It depends on how you define "portability". While it might help some broken software, it will hurt good one. > As defined, n32 provides all the benefits of 64-bit data (yes, you have > to use long long to get to it), and 100% backward compatability with So you can't use long to keep a file position pointer (off_t is quite a new invention) and have to go for long long, for example? Weird and definitely doesn't help portability. > o32 sources that assume (sizeof(void *)) = sizeof(long), plus binary data Thay should be fixed, instead. Using "void *" as a data container doesn't work in general and one who does so should be banished. And the other way round, there is no problem -- if one keeps 32-bit pointers in 64-bit longs, there is no bit loss. > file compatability with o32 as all structures are exactly identical between > o32 and n32. Why don't use o32 as is then, instead of creating a slightly different ABI? If some software needs binary data to be identical, then it has to select fixed-size types, e.g. int32_t, explicitly. While int32_t and friends are quite a new standard, other ways were used for years to set up such aspects, e.g. autoconf, imake, hand-written system-specific preprocessor macros, etc., etc. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
