>> 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
>
> Albert, Albert, Albert. You never cease to amaze me.
>
> Let's dissect your message a bit, shall we?
Sure, but in fairness I must rip apart your silly rant.
Note that the kernel makes EVERY ONE of the above assumptions.
The kernel even assumes a stricter version of #13, and it assumes
that you have big-endian or little-endian hardware.
> > You may assume:
>
> See, you went wrong right from the start. I thought that every 10 year
> old knows that when you ass-u-me something, all you do is make an Ass
> out of U and Me. And that would appear to be the case here.
Well, I won't argue about you being an ass, but you didn't need my
help to be one. This is a lame old joke.
> > 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
>
> Huh? There are lots of machines for which one or more of these
> things are not true
Yes, none of which run Linux. If you want to have an Atari 800XL
emulate a CPU with enough address space to run Linux, and you want
to page at a sub-OS level (microkernel Linux) across a serial line,
then you can damn well emulate a proper CPU as well.
> and #8 is amazing in it's shortsightedness.
> What part of Moore's Law do you not understand?
What part do you not understand? Rule #8 is good for at least
a dozen years, perhaps even 2 decades. Even then, there will be
ways to avoid the problem for quite a while.
Fine, you don't like the rule. You fix Linux. Go ahead, it is GPL.
If you do this, then CodingStyle can be updated for the new type.
> I could go on, but I fear that it would fall on deaf ears.
Nope, but the ears are connected to a practical person.
I'll repeat this for you, since it didn't sink in:
: 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.
> I can only
> plead that you not listen to Albert's suggestions. Perhaps Henry can
> add some wisdom, the following is as true today as it was when it was
> written some 15 years ago.
That was before the 1989 ANSI C standard. That was before the
world decided that all workstation and server CPUs would address
8-bit units of memory and have registers in nice power-of-two
sizes. That was long long before the 1999 ISO C standard.
Oh well, it is very funny today.
> Point #10 would be the one that our good
> friend Albert has overlooked.
>
> --lm
>
>
>
> The Ten Commandments for C Programmers
>
> Henry Spencer @ U of Toronto Zoology
>
>
> 1 Thou shalt run lint frequently and study its pronounce-
> ments with care, for verily its perception and judge-
> ment oft exceed thine.
Try that on the kernel. Have fun with libc too.
> 2 Thou shalt not follow the NULL pointer, for chaos and
> madness await thee at its end.
Well, yes, unless you write your own OS and want to reorder
your code a bit for better performance.
> 3 Thou shalt cast all function arguments to the expected
> type if they are not of that type already, even when
> thou art convinced that this is unnecessary, lest they
> take cruel vengeance upon thee when thou least expect
> it.
Know the promotion rules.
> 4 If thy header files fail to declare the return types of
> thy library functions, thou shalt declare them thyself
> with the most meticulous care, lest grievous harm
> befall thy program.
No. Thou shall return thy defective product.
> 5 Thou shalt check the array bounds of all strings
> (indeed, all arrays), for surely where thou typest
> ``foo'' someone someday shall type ``supercalifragilis-
> ticexpialidocious''.
Assuming you actually care... If it hurts, Don't Do That.
What you get is what you deserve. Hey, maybe I want overflows.
> 8 Thou shalt make thy program's purpose and structure
> clear to thy fellow man by using the One True Brace
> Style, even if thou likest it not, for thy creativity
> is better used in solving problems than in creating
> beautiful new impediments to understanding.
Heh... that would be GNU style? >:->
> 9 Thy external identifiers shall be unique in the first
> six characters, though this harsh discipline be irksome
> and the years of its necessity stretch before thee
> seemingly without end, lest thou tear thy hair out and
> go mad on that fateful day when thou desirest to make
> thy program run on an old system.
Oh yeah... and case insensitive too, and don't forget about
the 64 kB limit on malloc either.
> 10 Thou shalt foreswear, renounce, and abjure the vile
> heresy which claimeth that ``All the world's a VAX'',
> and have no commerce with the benighted heathens who
> cling to this barbarous belief, that the days of thy
> program may be long even though the days of thy current
> machine be short.
Sure, but some insignificant parts of the world do indeed suck
so bad that they are best ignored.
-
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/