# Drill Bits - Schrodinger's Code (Highlights)

## Metadata
**Cover**:: https://readwise-assets.s3.amazonaws.com/static/images/article1.be68295a7e40.png
**Source**:: #from/readwise
**Zettel**:: #zettel/fleeting
**Status**:: #x
**Authors**:: [[Drill Bits]]
**Full Title**:: Schrodinger's Code
**Category**:: #articles #readwise/articles
**Category Icon**:: 📰
**URL**:: [queue.acm.org](https://queue.acm.org/detail.cfm?id=3468263)
**Host**:: [[queue.acm.org]]
**Highlighted**:: [[2021-07-25]]
**Created**:: [[2022-09-26]]
## Highlights
### Sanity vs. Speed
- Early in the history of programming languages, two schools of thought diverged
#c1
- The behavior of every syntactically correct program should be completely predictable from its source code.
#c2
- A different philosophy reigns in domains that demand efficiency and speed
#c3
- By declaring that certain coding errors yield undefined behavior, language standards permit compilers to skip runtime checks and optimize aggressively. They also shift the burden of ensuring predictability onto the programmer.
### Guesswork
- Predicting the behavior of undefined code, however, is a fool's errand. Experiments merely record what happened when undefined code ran in the past. They can't predict the future
### Undefined Behavior in Vitro
- The C and C++ language standards decree that execution Shalt Not reach undefined code; the if branches in figure 1 obviously execute undefined operations; therefore, the if branches must be unreachable and may be omitted.
### Taking Action
- compiler writers have given notice that they will continue exploiting the liberties granted by the language standards.
- Other developers disable compiler optimizations in the hope of obtaining predictable behavior from undefined operations, as some versions of the Linux kernel and some open-source programs have done.14 This approach relies on nonstandard, nonportable features of particular compilers, and it impairs performance.
- The correct approach, of course, is to write software whose behavior is predictable according to the relevant language standards.
### Flagging Meaningless Code
- Developers might expect GCC's -Wall flag to live up to its name, but it actually enables only a fraction of available warnings. -Wextra adds several more, but many must be requested individually. For example, neither -Wall nor -Wextra activate -Wnull-dereference checks.
- Furthermore, some warnings rely on optimization. For example, both -Wall and -Wextra warn about use of uninitialized variables, but GCC performs the required analyses only if optimization is enabled too.
- compiling and linking both files with GCC's -flto flag yields a warning as a side effect of link-time optimization.
- Strive for a clean build with as many warnings enabled as possible; compile once with optimization disabled (-O0) and again with -O2 or -O3. Try to catch bugs spanning translation units using features such as link-time optimization.
- For bonus points, additionally employ a good lint-like tool or a static analyzer
### Case Study: Redis
### Drilling Deeper
- In addition to warning about bugs at build time, compilers can also instrument programs to detect undefined behavior at runtime. Check out GCC's -fsanitize and similar features in Clang.