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 think it should be simple. Furthermore, C is standardized, so why are implementations diferent in these OSes? Why is it hard to follow the standard and implement a universal library for all OSes?

I have programmed in C for almost two years, and currently I use glib for portability.

I'm not looking for a solution to this problem, I'm already using glib for this purpose. But I want to know why it is necessary, why it's dificult to make a C library without differences.

[ADD]

For example, when i write a program in C/Glib, i use the gchar/gint and so on types indeed the C primitive types, in wikipedia about glib, it says that :

"Features

On an elementary level GLib provides type definitions replacing the C primitive types char, int, float, and so on in order to improve portability"

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

Thanks for all the answers.

Answer 1

Making your basic C program that computes a little and prints results work is easy.

The problem is that any C program that does anything substantial is going to rely on a lot of services from the operating system, and those differ in many ways. File I/O tends to be similar, but when it comes to graphics, they differ a lot. And that is the crux of the problem.

Answer 2

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

At the time C was created, it was deemed most important that int use the natural word size (or halfword size) of the target machine (which in those days could have been 18 or 36 bits on a PDP-10!), and less important that the number of bits in an int be easily predictable, let alone the same on all hardware. Efficiency was of paramount concern, and it was especially important that a program not have too many instructions, so that it could be packed into the small memories of the day. Nobody would want to, for example, simulate 32-bit arithmetic on a 16-bit machine—that might triple the number of instructions needed to do arithmetic, making it impossible to fit larger programs into memory.

Why is it hard to implement a universal library?

It's not hard at all. The problem is not that there is no universal library; the problem is that people can't agree on what constitutes a universal library. (See: GTK, KDE, QT, AT&T U/WIN+AST, and so on ad nauseam.) But implementing a good library is really hard. As to why it's hard: library design is just a hard problem, and reasonable people can and do disagree on what constitutes a good design. So multiple designs proliferate, and portability goes by the board.

The situation is exacerbated by the very thin standard library that comes with C. But let us not forget that library was designed in the days when a programmer was lucky to get 64KB for code and another 64KB for data. By the time C++ came along, they could afford to standardize on an immense bloated hog like the Standard Template Library. But when the C library was designed, things had to be small. Now, when the standard C library is inadequate for today's more ambitious applications, it's too late for all C programmers to agree on a single standard.

---

Poke a professor, get a lecture...

Answer 3

It is not hard if you stick to the core standard (the examples in K&R will generally run with minimal correction). But the core standard does not support many things that people would like to do. Little things like:

• rooting around in the file system
• more sophisticated IO than plain streamed text
• asking the OS for access to clocks and printers and networks
• talking to other processes

---

Concerning the portability of the primitive types: the standard specifies minimum size limits for these types, but does not specify actual sizes. Most platforms support sizes that are larger than the minimums, but not all platforms have the same larger sizes. So glib and other cross-platform projects define their own type so that they only need one set of #ifdef switches to get the sizes right.