1972 April. Cherry blossoms bloomed in Cambridge Park, but MIT’s AI Lab was in open revolt over the glacial speed of ARPANET. 300 kilometers south of New York, at Bell Labs, Dennis Ritchie hunched over a PDP-11/20—its green phosphor screen glowing, its memory a mere 24KB, its hard drive smaller than a modern USB stick. His mission was deceptively simple: rewrite the entire Unix operating system from assembly into a “higher-level” language, one that could run on other machines.

He set himself a brutal goal: “Code written in this language must generate assembly as fast and compact as handwritten code. Not a single extra byte allowed.”

And so, C was born.

It was an era without function prototypes. An era where writing int flag; and then if (flag = 1) wouldn’t trigger a single compiler error. An era where every programmer fancied themselves a hardware expert, coding while smoking cigarettes and sipping coffee, punching code onto paper tape. To them, a boolean value? It was just 0 and 1. The CPU’s conditional jump instructions only recognized zero and non-zero—why bother with a boolean type? Adding a new type meant an extra conversion, an extra cycle wasted—and that was tantamount to murder.

1973 By, 90% of Unix had been rewritten in C. The kernel was just 9,000 lines long and ran on less than 50KB of memory. Ritchie and Thompson bragged about this feat everywhere: “We run a multi-user time-sharing system on 50KB of memory. IBM can’t do that with megabytes!” In this culture where frugality was king, anyone who dared say, “I want a bool type” would be met with stares of utter contempt, as if they were a fool.

1974 In, Unix left Bell Labs for the first time, making its way to universities. When students got their hands on the source code, their first reaction wasn’t awe—it was “What the hell? How does if (x=1) even compile?!” But no one dared fix it. Changing it would add 2 extra bytes, and in an age where magnetic tapes were expensive, 2 bytes meant 2 extra dollars—enough for 4 gallons of gas, enough to drive a Chevrolet to New Jersey for a joyride.

1978 saw the publication of The C Programming Language (the K&R Bible). That slim blue book contained a line that became gospel for the entire industry: “There is no need for a separate Boolean type.” In plain terms: Boolean values? They didn’t exist. If an int could do the job, never add a new type. Back then, the programmer community was small, filled with hardcore systems developers. Those who cut their teeth on assembly saw nothing strange about using 42 as “true”—they thought it was flexible.

1980s By the early, C began to infiltrate embedded systems. An engineer at an automotive electronics firm used the return value of “speed > 3000” as a boolean check in an engine control program. During testing, a faulty sensor returned -1, which the program still interpreted as true—nearly sending the test car careening to redline. The engineer laughed and slapped his thigh afterward: “Thank god C is wild. Any other language would have crashed.” These “hacky” solutions weren’t bugs back then—they were experience. But trouble was brewing beneath the surface.

1983 In, Microsoft started writing the DOS kernel in C. Programmers discovered that using int as a boolean led to costly bugs in large projects. For example, a function returning “-1 for error, 0 for success” might be naively checked with if (function()), turning error conditions into “true”. Microsoft’s solution was brute force: they defined their own BOOL type with typedef int BOOL, then #define TRUE 1 and #define FALSE 0. No sooner had Microsoft created this proprietary standard than the Unix camp followed suit.

1985 In, the first inklings of the Linux kernel emerged. Linus Torvalds thought Microsoft’s BOOL was overly verbose, so he simply wrote #define true 1 in the header files, skipping the type definition entirely. The chaos worsened among embedded vendors: Motorola’s 68000 SDK used “BOOLEAN”, Texas Instruments’ DSP tools used “Bool”—no consistency in capitalization or spelling.

1987 brought a disaster that laid the conflict bare. A bank upgraded its transaction system, porting Windows code to a Unix server. Windows’ BOOL was an int (4 bytes), while Unix’s Bool was typedef’d to char (1 byte). During data transmission, the 4-byte TRUE (0x00000001) was truncated to 1 byte (still true on Unix), but the error code 0x000000FF was interpreted as true on Windows (as an int) and false on Unix (as a char)—resulting in the loss of over 100 transaction records.

Bank programmers cursed over the logs for three days, finally fixing the issue with a mess of type casts. Word spread throughout the industry, and more and more developers called for a standard boolean type for C.

Thus, the 1989 ANSI C (C89) standardization meeting put “whether to add a boolean type” at the top of its agenda.

Supporters banged the table: “We’re writing tens of thousands of lines of code now—using int as a boolean is digging our own graves!” Opponents, representatives from embedded and systems vendors, echoed the same arguments that would resurface in C99: “We have nuclear power plant control code from 1979 that uses flag=5 as true. Who takes responsibility if we change it?”

More crucially, C’s “myth of minimalism” remained unbroken. Many veteran experts insisted: “C is a language for smart people—no need to coddle beginners.” One senior engineer who worked on Unix snapped: “We wrote Unix in assembly without even an int type, and it worked fine! Kids these days are just soft.”

The final vote passed “no boolean type for now” by a narrow margin. The C89 standard only noted: “When using integer types for boolean values, 0 is false, non-zero is true”—passing the buck right back to programmers. A tech magazine’s review hit hard after the standard’s release: “C’s flexibility is really just shifting all risk to the user.”

1990s The early made things worse. C++ rose to prominence, and its 1990 draft standard explicitly added the bool type. Bjarne Stroustrup (the father of C++) stated bluntly in a speech: “C’s type system is too loose—bool is a safety lock for code.” This ignited cross-language conflicts: a C code line like int flag=2 passed to a C++ function would be interpreted as true, even if the programmer intended 2 to represent a state, not a boolean value.

1995 Java’s birth in, with its native boolean type, made C programmers even more frustrated. Even beginners knew “true is true, not 1”. Meanwhile, C developers stuck to int while their C++ and Java colleagues used bool/boolean—explaining “why 3 is true” during code reviews took up ten minutes each time.

By 1998, the C++98 standard was officially released, making bool a first-class keyword alongside int. At the same time, the internet industry boomed, with C codebases of 100,000 or even a million lines common. Bugs from using int as a boolean grew more absurd: an e-commerce site showed “in stock” when inventory was -1 (out of stock); a communication device skipped alarm logic when signal strength was 0 (no signal), interpreting it as false.

1999 In, the C standards committee finally caved. What followed was one of the most awkward moments in C’s history: someone proposed adding bool, true, and false as keywords, just like C++. The words hung in the air, and the room fell deathly silent.

Then a representative from a veteran embedded vendor raised his hand slowly: “I’m sorry, but our company has 3 million lines of assembly-C hybrid code from 1987 that uses ‘bool’ as a variable name over a thousand times. If bool becomes a keyword, our entire product line won’t compile tomorrow.”

A representative from a telecom giant chimed in: “We have 2 million lines of code with #define bool int in the macros. Changing the keyword would mean rewriting our entire history.”

Finally, a white-haired veteran who’d worked on ANSI C89 sighed and said something that silenced the room: “We skipped adding bool to save one byte back then. Today, we’re sacrificing the entire ecosystem for that single byte.”

And so, they made what would be called C’s “most dignified surrender”:

• Add a new underlying type called _Bool;
• Provide an optional header file <stdbool.h>, which aliases _Bool to bool, 1 to true, and 0 to false via macros;
• Use it if you want, stick with int if you don’t—no one gets offended.

C99 was officially released in 1999 December. No one dared laugh, because everyone knew the truth: this was the fate of standards—they always dance on the grave of legacy code.

In the first month after C99’s release, tech forums were flooded with complaints that could fill a book titled The Half-Baked Solution Complaints Collection. Someone posted a code snippet: "#include <stdbool.h> bool flag = true;" with the comment: “Finally no more int flag = 1;—but it feels like stealing from C++.” Others shared screenshots of cross-platform code: Windows side avoided the header to maintain compatibility with old code, Unix side relied on it for new code, with a clumsy compatibility macro stuck in the middle: "#ifdef _WIN32 #define bool int #endif"—ugly enough to make your eyes hurt.

Embedded developers had it worst. An engineer at a military contractor ranted on a forum: “Our missile control systems still use a C89 compiler—management says stability is everything. I tried using _Bool in a new module, and the compiler threw ‘unknown type name’. Ended up back to int flag;—this standard means nothing to us.”

The next decade was the most humiliating for C programmers.

2005 In, as Google rose to fame, its internal coding standards flatly stated: “Ban bool in C code—use int instead. Reason: too much legacy code, consistency eases maintenance.” This anti-C99 rule stayed in place until 2018.

2008 saw the launch of the iPhone and the rise of Objective-C. Apple dropped a line in the Foundation framework’s header files that broke C programmers worldwide:

typedef signed char BOOL; // Note: YES = 1, NO = 0, -1 is also YES!

This meant values like -1 and 255 (true in C) were still YES in Objective-C, but stored as 1-byte signed chars.

Chaos ensued: C’s bool was a _Bool macro (usually 1 byte), C++’s bool was a native type (fixed at 1 byte), and Objective-C’s BOOL was a signed char (1 byte, but sensitive to the sign bit). Developers tested this: passing "bool flag = 255;" from C to Objective-C resulted in -1 (due to signed char overflow from 127) but still YES; passing an Objective-C BOOL value of -1 back to C++ converted it to true as an int. The results seemed the same, but the memory values of variables didn’t match—debugging cross-language interfaces could keep you up for three nights straight.

Time flew to 2011, and the C11 standard was released. Someone proposed elevating bool to a keyword, but the idea was shot down immediately. By then, billions of lines of C code were in use worldwide—those 3 million lines of embedded code from 1987 might still be running in factory equipment, and no one dared touch that landmine. All C11 could do was add a line to C99: “_Bool types can only hold 0 or 1”—a flimsy safety lock for this half-baked type.

New programming languages sprouted up like mushrooms, each one embarrassing C:

• Go (2009): Native bool
• Rust (2015): bool only has true/false
• Swift (2014): Even Optional<bool> is fully supported

Every new language felt like a lecture to C programmers: “See? No header files needed here.”

And the C standards committee? They stayed silent for 25 years.

Until 2024 October 31, when ISO/IEC 9899:2024 (C23) was officially released.

This compromise had already seen a major upgrade in 2023, when the C23 standard put the boolean type’s elevation back on the table. A quarter-century after C99, most of the millions of lines of legacy code that once tied the committee’s hands had been retired with equipment upgrades, and younger developers’ demand for type safety outweighed historical baggage.

In the WG14 meeting room that day, a 70-something committee member—one of those who voted against bool decades earlier—stood up, his voice trembling:

“Everyone… on behalf of my generation, I apologize to programmers worldwide. We saved one byte back then, and we’ve plagued you for half a century. Today, bool, true, and false are finally keywords.”

C23’s changes to the boolean type were a gentle revolution, not overturning C99 but fixing its worst flaws:

1. bool, true, and false became official keywords, with a safety valve: if these names were #defined in code, the compiler would prioritize the user’s definitions to avoid breaking legacy code;
2. <stdbool.h> was no longer optional, but an implicit part of the standard library—no need for #include to use bool, ending the awkwardness of relying on a header for compliance;
3. C23 fixed C99’s ambiguous size issue: sizeof(bool) is explicitly 1 byte, aligning perfectly with C++’s bool.

Cross-language developers breathed a sigh of relief: no more casting bool to int when passing values—C’s bool and C++’s bool now worked seamlessly, cutting debugging time for type-related bugs by half.

The news reached tech forums, and programmers reacted with mixed feelings. Someone posted a C23 test code snippet: "bool success = (a == b); if (success) { ... }" with the comment: “I’ve waited half my life for native bool in C.” But embedded veterans grumbled: “Our industrial controllers still run on C99 compilers—vendors charge for upgrades. C23 is great, but it doesn’t matter to us.”

In short, bool was finally free.

Today, writing C code means choosing between C23’s native bool (for type safety) or sticking with int flag (for compatibility with decades-old devices). Just as a boolean’s essence is always 0 and 1, C’s essence is always adapting to the present, compatible with the past.

This story, born from a fight over a single byte, ends with compromise.

C was never the most elegant language—but it is the one that understands survival best.

Perhaps that’s the ultimate wisdom of programming languages: not chasing perfect solutions in one step, but retaining the resilience to move forward with the times.