A note on standards

This section describes what the ISO C Standard is, and why you should care about it.

Introduction

The C programming language was created by Dennis Ritchie and Brian Kernighan in the early 1970s. It quickly gained popularity because it was small, efficient, and its code could be easily ported between different computer systems. For many years, the standard reference manual was Kernighan & Ritchie's book, "The C Programming Language".

However, despite this reference, compiler authors were free to implement the language however they chose, resolve any ambiguities in any way they chose, and provide any additional services they chose. The result was that code written to work on one system would often not work, or at least not work as expected, on another system, without significant modifications.

To remedy this, "in 1983 the American National Standards Institute (ANSI) established a committee whose goal was to produce 'an unambiguous and machine-independent definition of the language C,' whilst still retaining its spirit" ("The C Programming Language", second edition).

In 1990, ISO (the International Organisation for Standardization) and IEC (the International Electrotechnical Commission) issued ISO/IEC9899, an international standard "(specifiying) the form and (establishing) the interpretation of programs expressed in the programming language C". This was superseded in 1999 by a new standard from the same organisations. Unfortunately, since ANSI and ISO make their living through selling standards, this document is not legally available for free download.

The language described by this standard is known interchangeably as "ANSI C", "ISO C", and "standard C". The language existing before the standard, and described in Kernighan & Ritchie's first book is often known as "K&R C".

In short, the ISO C Standard describes what the C programming language is, how to use it correctly, what it can do, and what it can't do. It is a very important document, and every C programmer should be at least familiar with it, if not expert in every detail. The Usenet newsgroup comp.lang.c is an excellent place to learn correct, standard C programming. You should read the FAQ before posting there.

Why have a standard?

According to the abstract in the latest C standard:

[The Standard's] purpose is to promote portability, reliability, maintainability, and efficient execution of C language programs on a variety of computer systems.

Each of these factors is discussed below:

Portability
refers to the ability of a program to compile without problems, and execute as expected, on a wide variety of different computer systems.
Reliability
refers to the ability to be sure that your program will work as expected on a wide variety of computer systems, without having to worry about whether different compilers will interpret the same code in different ways.
Maintainability
refers to the fact that when written according to a prescribed set of rules, a program can be extended, debugged, checked and maintained by any person who is familiar with those rules. This avoids having to train new staff in a closed, proprietary language or dialect, regardless of the program or computer system being used.
Efficient execution
refers to the fact that when the behaviour of a given code snippet is well known, it can be relied on to exhibit that behaviour on a wide variety of computer systems. Therefore, code that is efficient on one platform will be efficient on another.

Thus, the key is in the phrase a variety of computer systems. The situation is analagous to many other things which have national or international standards. For instance, when you buy a light bulb, as long as you buy the right type, you don't have to worry about whether it will slightly too small, or slightly too large for the light fittings in your house, because they are made according to a predetermined standard size. Equally, when you write a C program according to the rules laid down in the Standard, you can be sure that it will compile and execute as expected, no matter which computer system you use (providing the computer system itself has a conforming implementation).

For DOS and MS Windows users in particular, portability is often seen as somewhat unnecessary, perhaps because DOS and Windows are themselves closed, proprietary operating systems. In the UNIX world however, there is a large variety of systems which look and feel similar, but which are different enough to cause problems. Before the Standard, porting applications between these systems could be a long a troublesome process. After the introduction of the Standard, designers had a terms of reference by which they could build development tools which provide a consistent and reliable environment which, provided developers themselves stick to the rules, allow programs to be written which will build and run on any system with little or no modifications needed.

In short, if you write your code according to the Standard, it will:

What are the drawbacks?

Because the Standard aims at producing code which will work unaltered on a variety of computer systems, there is a necessary element of lowest common denominator; only those facilities which will be supported on all these systems can be specified.

In particular, the Standard does not specify how to create or manipulate computer graphics in any way. This is because:

Other facilities that the Standard does not deal with include:

This is not meant to be an exhaustive list.

So what good is the Standard?

A common, and perfectly reasonable question, is that if the facilities specified by the Standard are so limited, what good is it at all?

The short answer is that some common code is better than none. Almost all non-trivial applications will have to use non standard code. However, a surprisingly large amount of code can be written using pure standard C. If these parts of the application can be segregated from the rest, then only the non standard parts need be ported, rather than recoding the entire program.

Also, if you take another look at the list above, you will notice that many of the unsupported facilities deal with input and output (including storage). Often, the meat of the program can be written using standard C, and only the parts that get input from the user, and produce output, need be written using nonstandard extensions (although this is not always the case). A common object oriented programming paradigm is that the implementation should be separate from the interface. Separating what your program does from how it interacts with the user will also make your program easier to improve and extend, as you will not need to completely redesign the program just to make a change to the interface, or vice versa. This practice will also most likely result in a better designed and more well thought out application.

POSIX, and other standards

The situation is not as bleak as it may appear above. Although the ISO Standard described is the only formal standard applicable to the C programming language, there are a number of other "standards" of varying degrees of formality which can make porting applications dealing with facilities outside the scope of the Standard less painful.

POSIX is a standard dealing with programming and system-tool interfaces issued by the Institute of Electrical and Electronic Engineers (IEEE). As well as C library functions dealing with operating system calls, threads, file system management, signals, and process control, it also deals with more user oriented facilities such as the shell, command line utilities and so on. It was modelled on facilities already common in UNIX; Linux is a fully POSIX compliant operating system.

Other "standards" include: