Linked by Eugenia Loli on Mon 10th Oct 2005 16:48 UTC, submitted by Shlomi Fish
Permalink for comment 42707
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
More News »
Sponsored Links



Member since:
2005-06-29
C code should function the same on different architectures if you mind your types...
It's only when you get into things that aren't really within c's logic you get into trouble: Using ints as pointers, using shift operators, and writing asm sections.
As long as you are on a "c machine" and since Lisp machines seem to have dissappeared (physically speaking), I think you can be pretty sure you'll be on a "c machine."
Developers are conservative because they don't like menial tasks like porting that c code to the latest fad language. It's not perfection you need in a language, it's having it still be there in 10 years that you need. (Not to mention all the other important stuff, like not sucking so bad you can't do anything in it).
I'd say that code written in a portable language is portable.... It sort of "inherits" its portability from the portability of the compiler/runtime/machine. The trouble is that a lot of c code is written with a specific machine in mind, and that machine wasn't the c machine it was say Intel x86. So they did nice things like assuming sizeof *int == sizeof *(char *). Or assuming that int x = 1; x = x >> 48 would equal x >> 16.