On Aug 28,  6:01pm, khorben wrote:
} 
} I have been recently surprised to see that the following C program has a
} different output on Solaris 10 and NetBSD 3, for the same hardware (and
} both while using gcc):
} 
} [snip program]
} 
} So on Solaris 10 I obtain:
} $ ./sizes
} sizeof(char) = 1
} sizeof(short) = 2
} sizeof(int) = 4
} sizeof(float) = 4
} sizeof(double) = 8
} sizeof(long) = 4
} sizeof(long long) = 8
} 
} while NetBSD 3 gives:
} 
} $ ./sizes
} sizeof(char) = 1
} sizeof(short) = 2
} sizeof(int) = 4
} sizeof(float) = 4
} sizeof(double) = 8
} sizeof(long) = 8
} sizeof(long long) = 8
} 
} ok, the only difference is actually the size of long integers,
} respectively 32 and 64 bits. From my reading of the ANSI C standard I
} understood this is possible.
} 
} I have a few questions about this though, if appropriate:
} - who sets this?

     My guess would be the compiler.

} - why not keep long as 32 bits and let int default to 64 bits instead?

     Long must be at least as large as int, so this would be invalid.

}   This would help the short/long/long long hierarchy coherence, and let
}   int default to the native processor size (and 486 would be 16 bits!)

     The 486 is 32 bits natively when in protected mode.  To use 16 bit
ints would require an operand size override prefix on all register
operations.

} - has this ever been observed to cause portability or stability issues
}   on this platform?

     There has been tons of issues due to broken code.

} My concern is, I have seen programmers assume sizeof(int) or
} sizeof(long) are 32 bits, even while writing portable 32/64 bits code

     By definition that code is not portable, since it makes invalid
assumptions.

} Morale => #include <stdint.h> ?

     Or, don't make unnecessary assumptions.

}-- End of excerpt from khorben