History of C Programming Language
C is a general-purpose computer programming language developed in 1972 by Dennis Ritchie at the Bell Telephone Laboratories for use with the Unix operating system.
Although C was designed for implementing system software, it is also widely used for developing portable application software.
C is one of the most popular programming languages of all time and there are very few computer architectures for which a C compiler does not exist.
C has greatly influenced many other popular programming languages, most notably C++, which began as an extension to C.
The development of C occurred at AT&T Bell Labs between 1969 and 1973.
Aaccording to Ritchie, the most creative period occurred in 1972. It was named “C” because its features were derived from an earlier language called “B”, which according to Ken Thompson was a stripped-down version of the BCPL programming language.
The origin of C is closely tied to the development of the Unix operating system, originally implemented in assembly language on a PDP-7 by Ritchie and Thompson, incorporating several ideas from colleagues.
Eventually they decided to port the operating system to a PDP-11. B’s inability to take advantage of some of the PDP-11’s features, notably byte addressability, led to the development of an early version of C.
The original PDP-11 version of the Unix system was developed in assembly language. By 1973, with the addition of struct types, the C language had become powerful enough that most of the Unix kernel was rewritten in C.
This was one of the first operating system kernels implemented in a language other than assembly.
In 1978, Brian Kernighan and Dennis Ritchie published the first edition of The C Programming Language. This book, known to C programmers as “K&R”, served for many years as an informal specification of the language.
The version of C that it describes is commonly referred to as K&R C. The second edition of the book covers the later ANSI C standard.
K&R introduced several language features:
* standard I/O library
* long int data type
* unsigned int data type
* compound assignment operators of the form =op (such as =-) were changed to the form op= to remove the semantic ambiguity created by such constructs as i=-10, which had been interpreted as i =- 10 instead of the possibly intended i = -10
Even after the publication of the 1989 C standard, for many years K&R C was still considered the “lowest common denominator” to which C programmers restricted themselves when maximum portability was desired,
since many older compilers were still in use, and because carefully written K&R C code can be legal Standard C as well.
In early versions of C, only functions that returned a non-int value needed to be declared if used before the function definition; a function used without any previous declaration was assumed to return type int, if its value was used.
long int SomeFunction();
/* int */ OtherFunction();
/* int */ CallingFunction()
long int test1;
register /* int */ test2;
test1 = SomeFunction();
if (test1 > 0)
test2 = 0;
test2 = OtherFunction();
All the above commented-out int declarations could be omitted in K&R C.
Since K&R function declarations did not include any information about function arguments, function parameter type checks were not performed, although some compilers would issue a warning message if a local function was called with the wrong number of arguments, or if multiple calls to an external function used different numbers or types of arguments. Separate tools such as Unix’s lint utility were developed that (among other things) could check for consistency of function use across multiple source files.
In the years following the publication of K&R C, several unofficial features were added to the language, supported by compilers from AT&T and some other vendors.
* void functions
* functions returning struct or union types (rather than pointers)
* assignment for struct data types
* enumerated types
The large number of extensions and lack of agreement on a standard library, together with the language popularity and the fact that not even the Unix compilers precisely implemented the K&R specification, led to the necessity of standardization.
ANSI C and ISO C
During the late 1970s and 1980s, versions of C were implemented for a wide variety of mainframe computers, minicomputers, and microcomputers, including the IBM PC, as its popularity began to increase significantly.
In 1983, the American National Standards Institute (ANSI) formed a committee, X3J11, to establish a standard specification of C.
In 1989, the standard was ratified as ANSI X3.159-1989 “Programming Language C”. This version of the language is often referred to as ANSI C, Standard C, or sometimes C89.
In 1990, the ANSI C standard (with formatting changes) was adopted by the International Organization for Standardization (ISO) as ISO/IEC 9899:1990, which is sometimes called C90. Therefore, the terms “C89” and “C90” refer to the same programming language.
ANSI, like other national standards bodies, no longer develops the C standard independently, but defers to the ISO C standard. National adoption of updates to the international standard typically occurs within a year of ISO publication.
One of the aims of the C standardization process was to produce a superset of K&R C, incorporating many of the unofficial features subsequently introduced.
The standards committee also included several additional features such as function prototypes (borrowed from C++), void pointers, support for international character sets and locales, and preprocessor enhancements.
The syntax for parameter declarations was also augmented to include the style used in C++, although the K&R interface continued to be permitted, for compatibility with existing source code.
C89 is supported by current C compilers, and most C code being written nowadays is based on it. Any program written only in Standard C and without any hardware-dependent assumptions will run correctly on any platform with a conforming C implementation, within its resource limits. Without such precautions, programs may compile only on a certain platform or with a particular compiler, due, for example, to the use of non-standard libraries, such as GUI libraries, or to a reliance on compiler- or platform-specific attributes such as the exact size of data types and byte endianness.
In cases where code must be compilable by either standard-conforming or K&R C-based compilers, the __STDC__ macro can be used to split the code into Standard and K&R sections to prevent using on a K&R C-based compiler features available only in Standard C.
After the ANSI/ISO standardization process, the C language specification remained relatively static for some time. In 1995 Normative Amendment 1 to the 1990 C standard was published, to correct some details and to add more extensive support for international character sets. The C standard was further revised in the late 1990s, leading to the publication of ISO/IEC 9899:1999 in 1999, which is commonly referred to as “C99”. It has since been amended three times by Technical Corrigenda. The international C standard is maintained by the working group ISO/IEC JTC1/SC22/WG14.
C99 introduced several new features, including inline functions, several new data types (including long long int and a complex type to represent complex numbers), variable-length arrays, support for variadic macros (macros of variable arity) and support for one-line comments beginning with //, as in BCPL or C++. Many of these had already been implemented as extensions in several C compilers.
C99 is for the most part backward compatible with C90, but is stricter in some ways; in particular, a declaration that lacks a type specifier no longer has int implicitly assumed. A standard macro __STDC_VERSION__ is defined with value 199901L to indicate that C99 support is available. GCC, Sun Studio and other C compilers now support many or all of the new features of C99.
In 2007, work began in anticipation of another revision of the C standard, informally called “C1X”. The C standards committee has adopted guidelines to limit the adoption of new features that have not been tested by existing implementations.
* Some phrases/sentences were omitted.