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

[Jesse Pollard]

"Albert D. Cahalan" <[e-mail]>:
> Ben Pfaff writes:
> 
> > There is a lot of misinformation floating around here.  I feel
> > compelled to speak up.
> [...]
> > Citation: ANSI C89, section 6.5.2.1 "Structure and union
> > specifiers", as follows:
> 
> Who cares? Linux will NEVER work with a strict ANSI C compiler.
> In theory you are right, but in practice you are seriously wrong.
> 
> In anticipation of flames, I have the damn 1999 ISO C draft.
> I know full well that a "legal" compiler can put 42 chars of
> padding after everything and, just for fun, make every type
> be 101 bits wide.
> 
> Moderately portable code assumes a sane compiler and sane hardware.
> You may assume:
> 
> 1. The "char" type is 8 bits. It might be unsigned though. :-/
> 2. sizeof(short) == 2
> 3. sizeof(int) == 4      (for real Linux, not the 8088 hack)
> 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.
[snip]

#8 and #9 may be assumptions, but I think they are BAD assumptions and
should be avoided.

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

#9 is works as long as a pointer has the same number (or more) bits than
a long. This structure also encourages the INCORRECT (via assumption 8)
of things like (char *)(long) == (long)(char *). The VALUE  of the test
may be true, but one char pointer may still not be the same as another.

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

-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [e-mail]

Any opinions expressed are solely my own.