~ Return to the rest of the site
The C programming language was first described to the public in The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie, published by Prentice Hall in 1978. The language evolved out of the former B programming language, which was a product of Ken Thompson:
"""
Challenged by McIlroy's feat in reproducing TMG, Thompson decided that Unix—possibly it had not even been named yet—needed a system programming language. After a rapidly scuttled attempt at Fortran, he created instead a language of his own, which he called B. B can be thought of as C without types; more accurately, it is BCPL squeezed into 8K bytes of memory and filtered through Thompson's brain. Its name most probably represents a contraction of BCPL, though an alternate theory holds that it derives from Bon [Thompson 69], an unrelated language created by Thompson during the Multics days. Bon in turn was named either after his wife Bonnie, or (according to an encyclopedia quotation in its manual), after a religion whose rituals involve the murmuring of magic formulas.
""" (The Development of the C Language)
[Thompson 69] references K. Thompson, `Bon—an Interactive Language,' undated AT&T Bell Laboratories internal memorandum (ca. 1969)
. This is possibly Bon User's Manual.
Please get in touch if you have a hyperlink for this document as I can't find it indexed on any search engines.
This language described in The C Programming Language isn't the C programming language known by most.
It was a pre-standardization, relatively prototypical C, and rather than being codified in ANSI its primary documentation was the book by Kernighan and Ritchie (this book would later be known colloquially as K&R).
This was known as "pre-ANSI C" or "K&R C" and dubbed "C78" for the purposes of naming this page, in the same style as the later "C89", described in ANSI X3.159-1989, or "C11", described in ISO/IEC 9899:2011.
"C78" was also the name given to historical C by the c78(7)
manual page on FreeBSD 9.0.
"C78" is incompatible with "C89" and later standards. This page documents those incompatibilities and relative oddities.
I have never done (and probably never will do) extensive programming in pre-ANSI C. These incompatibilities were discovered out of Appendix C in The C Programming Language, 2nd ed. but are described further.
8
and 9
as valid octal digitsmain() { printf("%d\n%d\n%d\n%d\n%d\n%d\n%d\n%d\n%d\n%d\n", 00, 01, 02, 03, 04, 05, 06, 07, 08, 09 ); }
On my machine, the GNU C compiler emits the following errors (this omits warnings) for the preceding piece of code:
snippet.c:4:49: error: invalid digit "8" in octal constant 4 | 00, 01, 02, 03, 04, 05, 06, 07, 08, 09 | ^~ snippet.c:4:53: error: invalid digit "9" in octal constant 4 | 00, 01, 02, 03, 04, 05, 06, 07, 08, 09 | ^~
This is because in C (both pre-standardization and post-ANSI) integer constants with leading zeroes are parsed as octal (base 8) numbers.
In pre-ANSI C, 8
and 9
were valid octal digits corresponding to 010
(b8) and 011
(b8).
This is documented in The C Programming Language, Appendix A, subsection 2.4.1, and evidenced by the preceding code block.
The following is output of the compiled program in UNIX V6 on an emulated PDP-11:
0 1 2 3 4 5 6 7 8 9
This behavior exists within /usr/source/c/c0t.s
, which is a PDP-11 assembler file that parses integer constants (as far as I can tell).
This file provides getnum
, a function used in /usr/source/c/c00.c
.
My theory is that this behavior is a side-effect of a very efficient but imperfect method of parsing integer constants from a file stream.
This wouldn't be a significant or even noticeable error; most programmers wouldn't use 8
or 9
as octal digits anyway.
If not for its documentation within The C Programming Language it would probably be an obscure bug.
This is also mentioned in The C Programming Language, 2nd ed. in Appendix C.