To read all comments associated with this story, please click here.
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.
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."
Good Lisp implementations have existed for both Lisp machines and C machines. Good C implementations have never existed for a Lisp machine. What does that say about C's vaunted portability? You're basically saying: C is portable as long as you only try to port it to machines designed for C. Duh. Does that mean it is portable, or does that merely mean that it's so popular that most machines are designed for it?
Illusion ? It is the most portable language (of course, by portability we mean source code portability).
It's portable as long as your program only does portable things, like text processing and math.
However, C is a portability nightmare when it comes to things like networking, graphics, and several other things. Additionally, people talk about C like there's only one version of it. There are in fact several, the most popular of which are K&R, ANSI C 89, ANSI C 99, and GNU C. Yes, GNU C does add its own extensions, and yes programmers do use them. (It is possible to have vendor lock-in in open source, it just isn't as big of a problem when it happens.)
C is also unportable during the act of compiling and linking. There are several different C compilers that use different command line options. Commonly used C libraries can be placed in any number of locations and given any number of names on people's computers. That's why we have the mess that is the GNU autotools.
"Most portable language"?!? You know how easy it is to get endianess wrong or to use non-portable libraries in C (yes that's source compatibility even)? Now compare that to java or c#, or look at all the apps for ms-windows that can't/won't be ported to linux/unix and then look at all the java apps that run out of the box on linux, macos/x and windows.
Code portability with C means to the same compiler on a different platform. C Compiler compatibility is a different matter. Each compiler seems to have its own features and quirks which can cause the same C code to behave differently depending on which compiler it was compiled with (assuming it will compile the foreign code at all). And then of course there are platform dependencies in the actual code which are hard to avoid because nothing shields you from the system specific hardware and system specific libraries except programmer discipline.
Java has the advantage of a well specified language (unlike C), well specified run-time environment (unlike C) and well specified APIs (unlike C). The behavior of Java programs on different implementations of the run-time engine and compiled with different versions of the compiler against different implementations of APIs is well defined: anything deviating from the spec may be considered a bug. So you can can compile with the ibm compiler on AIX and test on webshpere, run on the sun jvm on solaris and jboss or use Jrockit to run it on win32 with bea weblogic. If any of this requires code changes you have encountered a bug in either the compiler, run-time environment or the API implementation. The before mentioned application servers are known to have interoperability issues due to different implementations of the huge amount of APIs they support.
Hopefully you'll understand that source portability is probably pretty damn close to perfect. Most of the portability problems of java programs from one platform to another are caused by api portability problems. For example the oracle implementation of the servlet API is on paper equivalent to the apache tomcat implentation. Indeed many applications that use this API run fine on both, but not all. The reason is that oracle did nog quite get all the semantic details right in their implementation. If you depend on the correct behavior of some of these things, you will encounter problems.
The problem isn't any different if you compare the SUN linux jvm and the win32 jvm. Indeed most of the java code of the library is identical for both platforms (no problems there). The native code it depends on however is not. A considerable part of the java API has been designed to cover up for native code portability issues (graphics, io, processes & threads). Sometimes it fails to do that properly and that's when you encounter problems porting java applications from win32 to linux or vice versa.





Member since:
All the time, we hear repeated that C is portable. This is a misnomer. It gives the wrong impression that identical code will work in the identical way on different architectures. It's not the PROGRAM that is portable, it's the LANGUAGE. It was abstracted so that programs could be written using the same language constructs on different machines; so that you as a programmer could immediately get familiar with another environment on another system; because the compiler was easy to port. But not that the compiler, or your program would give identical results.
This to my mind is one of C's greatest weaknesses - this illusion of portability.
There is a reason for C's longevity. But it's more due to the innate conservativeness of the internal computing world, which is paradoxical given the radical changes IT has brought to the external world, than any inherent strengths in C itself.
Geoff Gigg