This book is meant to follow an introductory book on C. It assumes that you have successfully written some programs in C and that you are familiar with the basics of variables, operators, functions, pointers, and structures. It does not assume that you know the more advanced features such as pointers to functions, pointers to structures, dynamic allocation, enumerations, typedef, bit-fields, union's, FILE I/O, or dynamic data structures; these will be covered herein.
Also covered are rules for reliable programming, programming with no surprises.
The book also introduces the important topics of data structures: arrays, strings, pointers, records, stacks, queues, double-ended queues ("deques"), trees, record files, and hashed files. Besides discussing the formal aspects of each data structure, we also present working general-purpose C functions that implement the technique.
From its conception in the early 1970's, the design of C allowed for small compilers that could run on small hardware. Extra checking was available from tools like lint, the "extended syntax checker" distributed with UNIX systems. Now, some of the checking that lint does has been incorporated into recent C compilers.
A new level of reliability checking has been introduced by run-time checking environments such as Safe C from Catalytix and bcc from Delft, such as enforcing strict bounds for arrays and pointers, catching overflow errors, use of uninitialized variables, etc. The trend toward greater automated assistance in programming has my support, and I hope the book is useful in this area.
In the future we expect to see greater use of the computer's reasoning ability to assist in the production of software for new devices. The existing techniques go by the names "artificial intelligence" and "expert systems." And just as a growing number of existing language translators produce C language as their intermediate output, I expect that we will see a growing interest in C as the output from "expert program writer" systems. In order to achieve the reliability that is needed for this level of automation, the properties needed in the generated code must be strictly verifiable. One of my intentions in this book is to prepare the way for new levels of expressive power in programming.
One of the central tenets of my approach to programming instruction is that there is an important difference between project code and publication code. Project code is written to achieve a programming purpose. It tends to make extensive use of software resources developed by the project team, especially headers and libraries. Appropriate use is made of defined types and defined constants for the usages that are typical in the project.
Publication code is written for journals, articles, and some textbooks. It uses only the standard headers and libraries.
I have chosen to present C in a "project code" style, because I think that this style comes closer to the realistic programming environment. Indeed, many of you will be working in an environment that has adopted our C Programming Guidelines as a local standard. But even if your local project standard is different, it will probably resemble the "project" style more than the "publication" style.
Working in "project" style means that more effort is needed at the start to create an environment of headers, but the effort pays off in readability and portability.
At the beginning of some sections you will find the notation "Topics assumed from previous book." Then a number of topics are listed, with page references to Learning to Program in C [Plum, 1983]. These assumed topics are covered in most of the introductory books on C. If you find that you are not familiar with one of the assumed topics, consult one of the introductory books first for further details. I have tried to make this book reasonably self-contained without recapitulating C language from the ground up.
This book's approach to reliable programming attempts to be a codifying of successful practice, building upon a growing number of successful applications in C. Rules for reliable use of C are presented which are based upon the experience of numerous working programmers.
One of the most frequent questions regarding a readable style for C is "where should code be commented and what should be in the comments." My approach to "properties of data" is meant to provide an important part of the answer to this question: the comment appearing on a variable's declaration should describe the defining property of the data, and anywhere in the code that this property is not true, there should be a succinct comment that documents this warning.
The C language and its library have been the subject of several standardization efforts during the middle 1980's. One effort was organized by /usr/group, an organization of commercially-oriented users of UNIX operating systems and similar other systems. In 1984, /usr/group published a "standard for computer operating systems that are functionally compatible with UNIX Operating Systems developed by AT&T Bell Laboratories." In particular, the function library associated with C was standardized in this document. Those who served as officers of the /usr/group Standards Committee include Heinz Lycklama, David Buck, Donald Kretsch, Michael Tilson, John Bass, Thomas Hoffman, and Eric Peterson.
In 1983, a committee was organized under the auspices of ANSI (the American National Standards Institute) to begin the standardization of C. This committee is under the administrative control of ANSI X3, the group responsible for computer systems, and is known as X3J11. Those who have served as officers of X3J11 and its subcommittees include Jim Brodie, P. J. Plauger, Ralph Phraner, Larry Ros1er, Ralph Ryan, and myself.
One of the early decisions of X3J11 was to adopt the /usr/group library standard as the starting point ("base document") for the standardization of the C library. Careful attention was paid to eliminating the system-specific aspects of this library; the eventual library specification for ANSI C is meant to be portable to all operating systems which provide support for C compilation and execution. As of the writing of this book (mid-1985), the current draft of X3J11 has been forwarded to ANSI X3 for publication as an Information Bulletin, one step short of a formal Draft Proposed Standard. Current expectations are for an ANSI standard for C to be adopted during the year 1986. Many vendors are already incorporating many of the features of this evolving standard, so you are likely to encounter these features with the next releases of your compilers.
This book attempts to provide a style of writing C which will allow compilation of programs both with current compilers and with new compilers that adopt features of the evolving standard. I have attempted throughout the book to inform you of the likely future direction of C. Still, there will be changes to the X3J11 draft before it becomes an official standard, so it must be understood throughout that none of this book is an official statement of the X3J11 committee. I especially ask reviewers not to cite my observations about the ANSI draft as representations of the final decisions of X3J11.
This book describes a style of programming that is compatible both with the (June 1985) draft of ANSI C and with a broad spectrum of existing compilers. The approach has been specifically verified against the compiler and library of UNIX System V (Release 2), Whitesmiths 2.3 and 3.0, Lattice 2.15, and Catalytix Safe C, as well as the library standardized by /usr/group. This level of C will be referred to as "recent C" in the book. But where it is specifically necessary to refer to the (draft) ANSI C standard, I have done so.
The official ANSI standard for C is expected during 1986, but the reliability advantages of recent C compilers are available now. The rules described in this book represent techniques that can be used now, with existing compilers, for maximum reliability in both the current and the future (ANSI C) environments.
There are a number of people whom I would like to acknowledge for their important contributions to this book. Yoram Bar-Am and Steve Bennett wrote the original version of the menu processor which I adapted for Chapter 6. Jim Brodie, Jim Ginn, Jim D'Ottavi, David Graham, Steve Hersee, Andrew Johnson, Bob Racko, Roland Racko, Christopher Skelly, and my mother, Ruby Schunior, read several drafts and made many helpful suggestions. Dave Brown, Dennis Cook, Debbie Fullam, Jim Griffin, Tom Hoffman, Paul Kleppner, Bill Koenig, Neil Ludlam, Mike Meissner, Ed Rathje, and Larry Rosler provided numerous helpful ideas during various stages of the book. Many thanks go to Joe Lochel for his clams and his friendship. Tim Cwik provided tireless assistance with the programming examples and the final production work. I am especially grateful to Roland Racko for writing the ev editor, which provides an identical screen-editing interface on the four different machine environments in our office. My thanks also to Whitesmiths, Ltd., for the reliability of the Idris systems, on which I did my development work up to the typesetting stage. Alan Feuer and Jonathan Lettvin advanced the state-of-the-art in C reliability with the Safe C environments and made numerous helpful suggestions, especially regarding the ranges of pointers. Brent Byers, the author of the Tplus formatter, provided valuable assistance with the typesetting. I am indebted to P. J. Plauger for many contributions: for pioneering the development of C compilers for a wide range of popular operating systems, for innumerable discussions of the subject matter across several continents, and for his careful reading of a preliminary draft of the book. My thanks should in no way imply that each of these people agrees with every one of my conclusions.
I also wish to thank Dennis Ritchie for designing a language of unique elegance, power, and utility.
There are some other people who made important contributions to the work which has culminated in this book. They include John Colligan, Paul Davis, Kee Dewdney, Dennis Geller, John Holland, G. M. Weinberg, Steve Robertshaw, J. A. Robinson, Gil Roeder, Steve Schustack, Barbara Smyly, Glenn Smyly, and Ed Yourdon. My sincere thanks to each of them.
My heartfelt thanks to all the staff of Plum Hall Inc -- Linda Deutsch, Suzanne Battista, Cathy Bertino, and Anne Hall -- for everything that they did to bring this book into existence. I am profoundly grateful to my late father, George E. Schunior, for his love and direction. And to my family, the Halls, McEvoys, Pritchetts, Richters, Schuniors, Schanzes, and Whynmans, goes my deepest gratitude for their steadfast support. To them, and especially to Joan Hall, my thanks for everything.