> 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.
Casting gets really nasty. There is no hope of porting Linux
to this system.
Compiler wish list:
1. -Wstruct-padding warn if compiler added padding
2. __bag__ like a struct, but the compiler chooses order
3. __align__ like the assembly language .align
-
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/