Prentice Hall-Expert C Programming Deep Secrets (Prentice-Hall)（Z-Library）

# Expert C Programming: Deep C Secrets — Reading Guide ## 【One-Line Pitch】 A masterclass in C's hidden corners and historical quirks from a veteran compiler-writer, perfect for working C programmers who want to move beyond syntax and understand why the language behaves the way it does. ## 【Book Arc】 - **Opening (~0%–9%)**: The author sets the tone with war stories (like the $20 million bug caused by `x==2` instead of `x=2`), explains the book's conventions, and frames C as a craft requiring years of experience to master. - **Early (~18%–32%)**: A deep dive into C's prehistory—the failed Multics project, Ken Thompson's creation of UNIX and the B language, and how hardware constraints shaped early design decisions. Includes the "Golden Rule of Compiler-Writers" and the first of several programming challenges (the time_t wrap-around problem). - **Middle (~41%–50%)**: Analysis of why C looks the way it does—features designed for compiler-writer convenience rather than programmer safety, including arrays starting at zero, type decay into pointers, the seemingly useless `auto` keyword, and the misguided `register` keyword. - **Middle (~55%–59%)**: Exploration of what was deliberately left out of the C compiler and pushed into the runtime library—I/O, memory management, and the C preprocessor's three purposes (string replacement, file inclusion, and code templates), with warnings about macro pitfalls. ## 【Key Takeaways】 - **C's design philosophy prioritizes compiler-writer convenience over programmer protection** (Middle): Unlike Pascal's type system designed to restrict programmers, C's type system was an afterthought to help compiler-writers distinguish data types on PDP-11 hardware. This explains why C permits unsafe assignments between different types—it was never designed to protect you. (Middle) - **Simple-looking code can hide expensive bugs** (Opening): The `x==2;` typo that cost $20 million in hardware sales shows that C's expression-oriented syntax will happily evaluate and discard results without complaint. This is why tools like `lint` and defensive habits like writing `if (3==i)` matter. (Opening) - **Performance is the golden rule for compiler-writers** (Early): Runtime speed dominates all other compiler concerns—error messages, documentation, and support pale in comparison. This explains many of C's design trade-offs, including why aggressive optimization can mask invalid code. (Early) - **C's features often exist because of historical hardware constraints** (Early–Middle): The PDP-7's 8K word memory forced B to be an interpreter, not a compiler; PDP-11 floating-point hardware led to double-precision promotion everywhere; arrays start at zero because compiler-writers think in offsets. Understanding the hardware explains the language. (Middle) - **Arrays and pointers are not equivalent, despite common belief** (Middle): Array names "decay" into pointers in expressions for compiler convenience, but treating them as always interchangeable is a mistake. The author promises a full treatment of this distinction in a later chapter. (Middle) - **What C leaves out, the programmer must supply** (Middle): Unlike languages that implicitly plant runtime support code, C requires explicit calls for memory management, variable-size arrays, bounds checking, and I/O. The standard I/O library was tuned down from an earlier, slower portable library. (Middle) - **The C preprocessor is powerful but treacherous** (Middle): Its three purposes—string replacement, file inclusion, and code templates—come with subtle dangers. A single space in a macro definition can completely change expansion behavior, as shown by the `#define a(y)` versus `#define a (y)` example. (Middle) ## 【Reading Tips】 - **Skim the historical chapters if you're in a hurry** (Early): The Multics and UNIX origin story is entertaining but not essential for practical C work. However, the "Golden Rule of Compiler-Writers" and the discussion of why features exist are worth reading even if you skip the history. - **Do the programming challenges** (Early): The time_t wrap-around exercise is a great hands-on way to understand both C's time functions and the subtle difference between `ctime()` and `gmtime()`—the author demonstrates that even "simple" date code has surprising twists. - **Pay special attention to the compiler-writer's perspective** (Middle): The section explaining why C features exist "for the compiler-writer's benefit" is the book's core insight. Understanding this philosophy will help you predict why C behaves unexpectedly in other situations. - **Watch for the macro examples** (Middle): The whitespace sensitivity in preprocessor definitions is a classic gotcha. If you use macros in production code, study this section carefully—it's the kind of subtle bug that wastes hours. - **Use the book as a reference, not just a read-through** (Opening): The author explicitly designed each chapter as self-contained sections, so feel free to dip into specific topics when you encounter a C problem rather than reading cover to cover. ## 【Coverage Limits】 This guide covers the opening through the middle sections of the book (approximately 0%–59%). The excerpts do not cover the later chapters on runtime data structures, arrays vs. pointers in depth, or the "light relief" sections at chapter ends. ##