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

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.

Answer 2

C does give more power compared to other higher level languages.

Different Processor (CISC and RISC based), 32 and 64bits does put the bit streams of data in different order. There are some supporting APIs to do the conversion, but not totally reliable for all cases.

Windows and Unix have custom flags which need to be used for building.

Answer 3

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 4

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 5

The code is portable, but thats not the problem.

The problem is that most larger applications use libraries which are part of the OS. So for example if you write a network app it might use the built in UPNP library for windows, and the Bonjour library on OS X, and some other zero-conf service on other unix flavors.

Another example would could a simple notepad application. It might use the native save-file dialogues for the OS it is running on. A different version would need to be compiled for each OS to bind to the save-file dialogue library for that OS.

I hope these examples are clear enough :)

Answer 6

I think it's because every compiler has a tension between being standard and portable on one hand and using optimal, OS-proprietary features on the other.

I think ANSI C code is quite portable, as long as you write to the standard. Your code is portable to the degree that GNU and Microsoft are both sticking to the standard.