Critiques on C Language

 

Two ideas are the most characteristic of C between the languages of its class: the relationship between arrays and pointers, and how the declaration syntax mimics the expression syntax. They are also among its most frequently criticized features, and often serve as stumbling blocks to beginners. In both cases, historical accidents or errors have exacerbated their difficulties. The most important of these was the tolerance of C compilers to type errors. As should be clear from the above history, C has evolved from a variety of languages. It did not suddenly appear to its early users and developers as a completely new language with its own rules; Instead, we had to continuously adapt the existing programs as the language was developed and make provision for an existing body of code. (Later, the ANSI X3J11 C standardization committee would have the same problem.)

Compilers in 1977, and even after that, did not complain about uses such as assigning between integers and pointers, or using objects of the wrong type to refer to the members of the structure. Although the language definition presented in the first edition of K&R was reasonably (though not entirely) consistent in its handling of the type rules, the book admitted that existing compilers did not enforce them. Besides, some of the rules designed to ease early transitions have contributed to later confusion. For example, empty square brackets in the declaration function int f(a) int

a[]; {....}

  

They are a living fossil, a remnant of NB 's way of declaring a pointer; an is, in this special case only, interpreted in C as a pointer. The notation survived partly because of compatibility, partly because of the rationalization that it would allow programmers to communicate to their readers an intention to pass a pointer generated from the array, rather than a reference to a single integer. Unfortunately, it serves as much to confuse the learner as it does to alert the reader.

 

In K&R C, it was the responsibility of the programmer to supply arguments of the proper type to a function call, and the existing compilers did not check for a type agreement. The failure of the original language to include the type of argument in the type of function signature was a significant weakness, indeed one that required the boldest and most painful innovation of the X3J11 committee to be remedied. The early design is explained (if not justified) by avoiding technological problems, in particular cross-checking between separate source files, and my incomplete assimilation of the implications of moving from untyped to typed language. The lint program mentioned above tried to ease the problem: among its other functions, lint checks the consistency and consistency of the entire program by scanning a set of source files, comparing the types of function arguments used in calls with those used in their definitions.

 

The syntax accident contributed to the perceived complexity of the language. The indirection operator, spelled * in C, is syntactically a unary prefix operator, as in BCPL and B. This works well in simple expressions, but in more complex cases, parentheses are needed to direct parsing.

 

For example, to distinguish indirection by a value returned by a function from calling a function designated by a pointer, one writes *fp() and (*pf)()respectively. The style used in expressions is followed by a declaration, so that names can be declared

int *fp();

int (*pf)();

 

In more ornate but still realistic cases, things get worse:

int *(*pfp)();

 

It is a pointer to a function that returns a pointer to an integer. Two effects are occurring. Most importantly, C has a relatively rich set of ways to describe types (compared, say, with Pascal). Statements in languages as expressive as C — Algol 68, for example — describe objects that are equally difficult to understand, simply because the objects themselves are complex. A second effect is due to the syntax details. Statements in C must be read in an 'inside-out' style that many find difficult to grasp [Anderson 80]. Sethi [Sethi 81] noted that many of the nested statements and expressions would have become simpler if the indirect operator had been taken as a postfix operator instead of a prefix, but by then it was too late to change. Despite its difficulties, I believe that the C approach to declarations remains plausible, and I am comfortable with it; it is a useful unifying principle.

 

The other characteristic feature of C, its treatment of arrays, is more suspect on practical grounds, although it also has real virtues. Although the relationship between pointers and arrays is unusual, this can be learned. Moreover, language has considerable power to describe important concepts, such as vectors whose length varies over time, with only a few basic rules and conventions. In particular, character strings are handled by the same mechanisms as any another array, plus the convention that a null character will terminate a string. It is interesting to compare C's approach with that of two almost contemporary languages, Algol 68 and Pascal [Jensen 74].

 

Arrays in Algol 68 either have fixed limits or are 'flexible:' a considerable mechanism is required both in language definition and in compilers to accommodate flexible arrays (and not all compilers fully implement them.) Original Pascal had only fixed-size arrays and strings, and this proved to be confined to [Kernighan 81]. Later, this was partially fixed, although the resulting language is not yet universally available.

 

C treats strings as character arrays conventionally terminated by a marker. Apart from a specific rule on string literal initialization, string semantics are fully subsumed by more general rules governing all arrays and, as a result, the language is easier to describe and translate than one that incorporates a string as a unique data type. Some costs arise from its approach: certain string operations are more expensive than other designs because the application code or library routine must occasionally search for the end of a string. After all, few built-in operations are available, and because the burden of string management falls more on the user. C's approach to strings, however, works well.

 

On the other hand, C's treatment of arrays in general (not just strings) has unfortunate implications for both optimization and future extensions. The prevalence of pointers in C programs, whether explicitly stated or derived from arrays, means that optimizer must be prudent and must use careful data flow techniques to achieve good results. Sophisticated compilers can understand what most pointers might change, but some important uses remain difficult to analyze. Functions with pointer arguments derived from arrays, for example, are difficult to compile into efficient vector machine code, because it is rarely possible to determine that one argument pointer does not overlap data that is also referred to by another argument or accessible externally. More fundamentally, the C definition so specifically describes the semantics of arrays that changes or extensions that treat arrays as more primitive objects, and allow operations on them as a whole, are difficult to fit into the existing language. Even extensions to allow the declaration and use of multidimensional arrays whose size is dynamically determined are not entirely straightforward [MacDonald 89] [Ritchie 90], although they would make it much easier to write numerical libraries in C. Thus, C covers the most important uses of strings and arrays resulting from a uniform and simple mechanism in practice but leaves problems for highly efficient implementations and extensions. 

 

There are, of course, many minor infelicities in the language and its description besides those discussed above. There are also general criticisms to be made, which go beyond detailed points. The most important of these is that language and its generally-expected environment are of little help in the writing of very large systems. The naming structure only provides two main levels, 'external' (visible everywhere) and 'internal' (within a single procedure). The intermediate level of visibility (within a single file of data and procedures) is weakly linked to the language definition. There is therefore little direct support for modularization, and project designers are forced to set up their conventions.

 

Similarly, C itself provides two storage duration: 'automatic' objects that exist while the control resides in or below the procedure, and 'static' objects that exist throughout the execution of the program. Off-stack, dynamically allocated storage is provided only by a library routine and the burden of managing it is placed on the programmer: C is hostile to automatic garbage collection.