C programming language: Encyclopedia II - C programming language - Criticism

C programming language - Criticism

A popular saying, repeated by such notable language designers as Bjarne Stroustrup, is that "C makes it easy to shoot yourself in the foot" [2] In other words, C permits many operations that are generally not desirable, and thus many simple errors made by a programmer are not detected by the compiler or even when they occur at runtime. This leads to programs with unpredictable behavior and security holes. In other words, "C is a sharp tool". It is certainly not a language for beginners in programming. The safe C dialect Cyclone addresses some of these problems.

However, C enthusiasts contend that the language's unforgiving nature, through exposing the programmer to all kinds of dangers, forces the programmer to take great care in coding, and, with diligence and perserverance, makes them better programmers.

Part of the reason for this is to avoid compile- and run-time checks that were too expensive when C was originally designed. Another reason is the desire to keep C as efficient and flexible as possible; the more powerful a language, the more difficult it is to prove things about programs written in it. Some checks were also relegated to external tools, such as those discussed in Compiler-external static-checking tools below. Nothing prevents an implementation from providing such checks, but nothing requires it to, either.

C programming language - Memory allocation

One issue to be aware of when using C is that automatically and dynamically allocated objects are not initialized; they initially have an indeterminate value (typically whatever value is present in the memory space they occupy, which might not even be a legal bitpattern for that type). This value is highly unpredictable and can vary between two machines, two program runs, or even two calls to the same function. If the program attempts to use such an uninitialized value, the results are undefined. Many modern compilers try to detect and warn about this problem, but both false positives and false negatives occur.

Another common problem is that heap memory has to be manually synchronized with its actual usage in any program for it to be correctly reused as much as possible. If the lifetime of the last pointer accessible by a live program variable ends (an auto pointer going out of scope, or being overwritten for example) and is referencing a particular allocation that is not freed via a call to free() then that memory cannot be recovered for later reuse and is essentially lost to the program. This is called a memory leak. Conversely, it is possible to release memory too soon, and then continue to use it, but since the allocation system can re-allocate the memory at any time for unrelated reasons, this results in unpredictable behavior (typically in parts of the program that are different from where the erroneous operations actually occured). These issues in particular are ameliorated in languages with automatic garbage collection or RAII.

C programming language - Pointers

Pointers are a primary source of potential danger. Because they are typically unchecked, a pointer can be made to point to any arbitrary location (even within code), causing unpredictable effects. Although properly-used pointers point to safe places, they can be moved to unsafe places using pointer arithmetic; the memory they point to may be deallocated and reused (dangling pointers); they may be uninitialized (wild pointers); or they may be directly assigned a value using a cast, union, or through another corrupt pointer. In general, C is permissive in allowing manipulation of and conversion between pointer types. Other languages attempt to address these problems by using more restrictive reference types.

C programming language - Arrays

Although C has native support for static arrays, it is not required to verify that array indexes are valid (bounds checking). For example, one can write to the sixth element of an array with five elements, yielding generally undesirable results. This type of bug, called a buffer overflow, has been notorious as the source of a number of security problems. On the other hand, since bounds checking elimination technology was largely nonexistent when C was defined, bounds checking came with a severe performance penalty, particularly in numerical computation. It is also, arguably, inconsistent with C's minimalist approach. (Actually, the decision to equate an array with a pointer to its first element, and to use this approach for passing arrays as function parameters -- without bounds information, pretty much ruled out bounds checking from the beginning.)

Multidimensional arrays are necessary in numerical algorithms (mainly from applied linear algebra) to store matrices. The structure of the C array is very well adapted and fit for this particular task, provided one is prepared to count one's indices from 0 instead of 1. This issue is discussed in the book Numerical Recipes in C, Chap. 1.2, page 20 ff (read online). In that book there is also a solution based on negative addressing which introduces other dangers.

C programming language - Variadic functions

Another source of bugs is variadic functions, which take a variable number of arguments. Unlike other prototyped C functions, checking the types of arguments to variadic functions at compile-time is impossible in general without additional information. If the wrong type of data is passed, the effect is unpredictable, and often fatal. Variadic functions also handle null pointer constants in a way which is often suprising to those unfamiliar with the language semantics. For example, NULL must be cast to the desired pointer type when passed to a variadic function. The printf family of functions supplied by the standard library, used to generate formatted text output, has been noted for its error-prone variadic interface, which relies on a format string to specify the number and type of trailing arguments.

Type-checking of variadic functions from the standard library is a quality of implementation issue, however, and many modern compilers do in particular type-check printf calls, producing warnings if the argument list is inconsistent with the format string. However, not all printf calls can be checked statically, since the format string can be built at runtime, and other variadic functions typically remain unchecked.

C programming language - Syntax

Although mimicked by many languages because of its widespread familiarity, C's syntax has been often targeted as one of its weakest points. For example, Kernighan and Ritchie say in the second edition of The C Programming Language, "C, like any other language, has its blemishes. Some of the operators have the wrong precedence; some parts of the syntax could be better." Bjarne Stroustrup has also derided C++'s syntax, which is very similar to that of C: "Within C++, there is a much smaller and cleaner language struggling to get out. [...] the C++ semantics is much cleaner than its syntax." [3] Some specific problems worth noting are:

• A function prototype with an empty parameter list allows any set of parameters, a syntax problem introduced for backward compatibility with K&R C, which lacked prototypes.
• Some questionable choices of operator precedence, as mentioned by Kernighan and Ritchie above, such as == binding more tightly than & and | in expressions like x & 1 == 0.
• The use of the = operator, used in mathematics for equality, to indicate assignment, leading to unintended assignments in comparisons and a false impression that assignment is transitive. Having = denote assignment and == equality was a deliberate decision by Ritchie, who noted that assignment occurs much more often than comparisons.
• A lack of infix operators for complex objects, particularly for string operations, making programs which rely heavily on these operations difficult to read.
• Heavy reliance on punctuation-based symbols even where this is arguably less clear, such as "&&" and "||" instead of "and" and "or" (though "and" and "or" are theoretically available as alternatives with the inclusion of a certain header).
• The un-intuitive declaration syntax, particularly for function pointers. In the words of language researcher Damian Conway speaking about the very similar C++ declaration syntax:

C programming language - Maintenance

There are other problems in C that don't directly result in bugs or errors, but make it harder for inexperienced programmers to build a robust, maintainable, large-scale system. Examples of these include:

• A fragile system for importing definitions (#include) that relies on literal text inclusion and redundantly keeping prototypes and function definitions in sync, and drastically increases build times.
• A cumbersome compilation model that forces manual dependency tracking and inhibits compiler optimizations between modules (except by link-time optimization).
• A weak type system that lets many clearly erroneous programs compile without errors.

C programming language - Compiler-external static-checking tools

Tools have been created to help C programmers avoid these errors in many cases.

Automated source code checking and auditing is fruitful in any language, and for C many such tools exist such as Lint. A common practice is to use Lint to detect questionable code when a program is first written. Once a program passes Lint, it is then compiled using the C compiler.

There are also compilers, libraries and operating system level mechanisms for performing array bounds checking, buffer overflow detection and automatic garbage collection, that are not a standard part of C.

Cproto is a program that will read a C source file and output prototypes of all the functions within the source file. This program can be used in conjuction with the "make" command to create new files containing prototypes each time the source file has been changed. These prototype files can be included by the original source file (e.g., as "filename.p"), which reduces the problems of keeping function definitions and source files in agreement.

It should be recognized that these tools are not a panacea. Because of C's flexibility, some types of errors involving misuse of variadic functions, out-of-bound array indexing, and incorrect memory management cannot be detected on some architectures without incurring a significant performance penalty. However, some common cases can be recognized and accounted for.

Adapted from the Wikipedia article "Criticism", under the G.N U Free Docmentation License. Please also see http://en.wikipedia.org/wiki