Why is it difficult to write portable C programs?

Question

I want to know, why is it too hard to make a program run in many OSes, like Windows and Linux, without including glue code. They all share the same architecture (x86), so I

Answer 1

Obviously, some software requires OS specific features, but it's quite interesting to think what can be created in C without using such things:

• A C or C++ compiler (though not all of the standard library)
• An assembler for any assembly language
• A linker for the above
• An interpreter for a scripting language
• Text processing tools like sed, grep etc.
• A simple editor (anyone remember ed?)

In fact, all the basic development tools can be developed (and historically were developed) in C without using OS-specific features.

Answer 2

For java/ruby/... somebody ported the VM and your code just runs. This makes it easy as long as you a ok with the services provided by the VM. In C you have to do all the work for your self because you can directly interact with the hardware and OS. This adds dependencies but but gives you great power and flexibility. This is what makes C great but it can be a pain if you switch OS or hardware.

Answer 3

Anything that your C program interacts with is going to be a dependency. If those dependencies are the exact same across every C implementation on all the systems, then you're in luck, your program is portable.

The basic file I/O operations are this way.

But if there is even one difference in the way your code is implemented on a system, it's not portable to that system anymore.

So, if your code doesn't touch anything, it's portable.

I think the main idea here is to maximize portability, so that you can minimize what you have to change to port to a new system.

Answer 4

Why C primitive types is not portable and the whole language?

The primitive types are portable in that they're guaranteed to support a minimum range of values (e.g., the int type must at least support values in the range -32767 to 32767). They're not guaranteed to have the same size or alignment restrictions because different architectures have different requirements.

The C standard tries to strike a reasonable balance between portability, performance, and ease of implementation, meaning that there are compromises in all three areas. It's possible to write C programs that are useful and trivially portable, but that means limiting yourself to a command-line driven interface, simple file I/O, and making no assumptions about word size or alignment.

Remember that C is a product of the early '70s, when the dominant computing environment consisted of large, time-share systems accessed via dumb character-based terminals; processor time and memory were expensive, and it was rare for a data center to support more than one or two different platforms at a time, so performance was the bigger concern than byte-for-byte portability. Forty years later that's no longer the case, but there's also forty years of legacy code to support, so the language definition can't change too radically.