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

Albert D. Cahalan (acahalan@cs.uml.edu)
Tue, 27 Jun 2000 19:05:27 -0400 (EDT)


Jesse Pollard writes:
> "Albert D. Cahalan" <acahalan@cs.uml.edu>:

>> 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
>>
>> One can define "good" struct layout as being an order that puts
>> items with the largest natural alignments first. For example, an
>> array of 6 shorts has a natural alignment of 4 bytes. I suppose
>> you could define natural alignment as gcd(16,sizeof(foo)).
>>
>> Every day I work with a system that violates rule 9.
>> From experience, I assure you that it is a mess to deal with.
>> Casting gets really nasty. There is no hope of porting Linux
>> to this system.
>
> #8 and #9 may be assumptions, but I think they are BAD assumptions
> and should be avoided.

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.

> 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.

> I personally don't like #11. Signed ints could cause a fault,
> but unsigned ints shouldn't (in my opinion).

I have mixed feelings about that one, but it is true.
One could hack up an __attribute__ that would work on the Alpha,
where integer instructions have faulting versions.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/