Re: ANSI C clarifications, with citations (was Re: [patch-2.4

[Jesse Pollard]

"Albert D. Cahalan" <[e-mail]>:
>Jesse Pollard writes:
>> "Albert D. Cahalan" <[e-mail]>:
>>> 4. sizeof(long) == sizeof(void *)
>>> 5. (sizeof(long) == 4) | (sizeof(long) == 8)
>>> 6. sizeof(long long) == 8       (good for 10 years at least)
>>> 7. You can freely cast between any two pointer types
>>> 8. You can freely cast between long and any pointer type
>>> 9. (long)(int*)(long)foo == (long)(char*)(int*)(long)foo
>>> 10. signed integers are represented in two's complement form
>>> 11. integers wrap around instead of causing faults
>>> 12. assuming "good" struct layout, padding only occurs at the end
>>> 13. ... that padding won't happen if you supply a multiple of 16 bytes

[snip]

>Very few systems violate those assumptions.
>
>#8 is obviously wrong for small-model 16-bit systems, but it
>should be equally obvious that Linux won't fit in 64 kB.
>The only recent system to violate #8 is Win64. Oh well...
>Porting to Win64 involves a whole lot more than just this.
>
>#9 dies on systems that use word pointers. Not even Cray has that
>problem anymore. I deal with a SHARC-based system that suffers
>from word pointers, but that is a DSP chip for embedded systems.
>The SHARC isn't even good enough for a palm-top computer.

Does on the SV1 Cray. It's still the old J90 base, with a different
implementation.

>> I believe the Sparc supports 64 bit pointers, as does the Alpha,
>> yet long is still 4 bytes. This violates assumption 8 (both 64 bit
>> mode of course).
>
>Linux makes sizeof(long)==8 on 64-bit systems, so the rule holds.

gcc must make that assumption, also it breaks binary compatability
between systems. A structure that was composed of 8/16/32 bit data
suddenly has 8/16/64, and potentially a lot of padding. That would
require converting the "int" into a field, which can't be supported
by pointers, packing becomes very nasty.. and filesystems cannot be
ported between otherwise compatable systems. 64bit sparc and 32bit sparc,
for instance. It also causes problems with mixing 32bit/64bit executables
which both Sparc/Alpha (and Intel) are supposed to support.

Nothing against them as assumptions, I just think they should be avoided
if possible.

Using the "types.h" definitions also means that the compiler will force
errors since a int32 is no longer the same size as an int, and int32 *
constructs fail (using a field definition for int32 again...).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [e-mail]

Any opinions expressed are solely my own.