~ Return to the rest of the site

K&R C

updated 2022-05-29


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 digits

main()
{
	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.