Type Safety: What Your Compiler Won’t Tell You

Reading Time: 6 minutes

Most modern languages quietly convert types for you: an integer becomes a float, a signed value becomes unsigned, a 32-bit number squeezes into 8 bits. The compiler is not at fault, the language permits it. These implicit casts are valid code, and they are also a major source of bugs. By the end of this post, you will know how to find every silent type conversion in your codebase, and decide which ones are safe to keep.

In 1999, NASA lost a Mars orbiter worth $327 million. The spacecraft was supposed to enter orbit around Mars, but instead burned up in the Martian atmosphere. The cause? One engineering team used imperial units (pound-force-seconds), while another wrote software expecting metric units (newton-seconds), and the program mixed the two silently. No warning, no type error, just a $327 million fireball.

I have seen the same pattern in embedded code. A 32-bit integer passed through a call stack gets narrowed to an 8-bit one somewhere along the way, without a word of warning. The value looks fine, prints fine, and even passes the tests, until it exceeds 255 and quietly wraps to zero. Two days to track that one down. The root cause was not a bug in any single line, but a mismatch the language was happy to paper over. To understand why, it helps to look at how languages treat types in the first place.

What is an implicit cast?

Many languages will quietly convert one type into another for you whenever the operation would otherwise not make sense. No warning, no error, just a conversion the language decided was reasonable on your behalf.

Here is a classic JavaScript moment:

console.log("5" + 5);   // "55"  — a string!
console.log("5" - 5);   // 0     — a number!

The “+" operator sees a string and a number, so it converts the number to a string, without asking. In contrast, the “-" operator sees two things that could be numbers, so it converts the string to a number. Both operations succeed without warning, but maybe not as intended.

In C, the same thing happens, often with worse consequences:

unsigned int x = -1;   // Silently becomes 4294967295
int y = 3.9;           // Silently truncates to 3

The compiler accepts both lines: your code compiles and your program runs. And somewhere, sometime, a bug appears that takes days to understand.

This is called an implicit type cast: the language converts one type to another automatically, without you writing a single explicit instruction.

Example from daily life: The measuring tape problem

Here is a way to picture this. You are building a shelf, and your tape measure shows both centimeters and inches. You measure each board and write down “30”, “45”, “60”, then your partner reads your notes and cuts the wood. She assumes inches, but you meant centimeters. The shelf is unusable, and no one warned you. The numbers looked fine.

That is what implicit type casts do: your variable holds 30. Is it a 32-bit integer? A 16-bit integer? A float? The compiler knows. But did you know, or the function receiving it?

In large code bases, this measuring tape problem compounds. Types travel through functions, get stored, get retrieved, get converted. At each step, an unmarked cast might happen, and a useful value quietly becomes something else. Nothing complains, until your software does.

What Static Analysis sees that your compiler doesn’t

Compilers are fast and built to accept valid code. Since implicit conversions are valid code in C, JavaScript, and Python, the compiler has no reason to flag them. In fact, optimizing compilers actively assume that undefined behavior never happens, and use that assumption to delete or rewrite code, as MIT researchers documented in detail.

Static Analysis was built to find problems, not just produce binaries, and it goes deeper. It can flag:

• Every implicit cast from a larger type to a smaller one (data loss)
• Every signed-to-unsigned conversion (unexpected wraparound)
• Every float-to-integer cast (silent truncation)
• Every comparison between signed and unsigned values (subtle logic errors)

Here is a concrete catch. A function reads a sensor value and packs it into a network byte:

uint8_t pack_reading(void) {
    uint32_t sensor_value = read_sensor();   // returns 0..1000
    return sensor_value;                     // silent narrowing to 0..255
}

The compiler accepts this without a peep. Static Analysis flags it directly: “Implicit conversion from uint32_t (range 0..1000) to uint8_t (range 0..255) at line 3 may lose data.” Notice what the analyzer brings to the table that the compiler does not: it tracked the range of sensor_value across function calls and compared it to the destination type. Every reading above 255 silently wraps. Two days of debugging avoided in two seconds. (And if you are curious what the analyzer does after reporting that finding, whether it keeps looking or stops, that is a separate story about blocking semantics.)

This does not mean all type casts are wrong. Sometimes a conversion is intentional and correct, and when it is, you can inject that knowledge into the analysis so the analyzer stops flagging it. Either way, Static Analysis gives you the complete picture: you see every conversion and decide which ones are fine.

“But my code already works”

I hear this a lot. “I know what I’m doing. When I want a cast, I write one.” That instinct is good and is the foundation of defensive coding. But every time? Unless you are using a strongly-typed language, you have probably missed a lot of casts.

The other argument is typically “this code has been running for ten years without problems, so whatever Static Analysis flags must be a false positive.” There is a name for the confidence that makes legacy code feel safe: survivorship bias. It is one of several cognitive traps that make Static Analysis harder to adopt than it should be. That code base has been running for ten years, so it must be correct. But what you have actually observed is the code surviving every input it happened to receive, not every input it could receive. The casts were always there; the values that would trigger them simply hadn’t arrived yet. “It works” and “it is correct” are not the same statement.

(I once ran this on a code base that had been in production for five years. The list of implicit casts was longer than the documentation.)

At the other end of the spectrum sit strongly typed languages, where the compiler enforces strict rules about how types interact and refuses most implicit conversions outright. Ada is the textbook example: it will not compile most of these mismatches in the first place. Mix a centimeter and an inch, and the compiler stops you. The measuring tape comes pre-labeled, and that matters. Another example of a strongly typed language is Rust.

However, even strongly typed languages have mechanisms to mix types, and these can fail, too. Ada offers explicit type conversions and Unchecked_Conversion. Rust offers From, TryFrom, and the as keyword. Safe variants either prove no data loss is possible (From) or force you to handle the failure case (TryFrom). But the escape hatches are explicit yet silent about losses: in Rust, 300_u32 as u8 compiles cleanly and yields 44, with no warning. Strong typing closes the front door, but the cast escape hatch is still wide open, and that is exactly where Static Analysis earns its keep.

Even if you believe that you don’t make mistakes with types, Static Analysis still pays off. Type systems only catch type errors, not logic errors, not dead code, not range violations the type cannot express. For that reason, Ada’s SPARK toolchain layers Formal Methods on top of strong typing to prove properties no type system can capture. Strong typing eliminates one class of bugs, and Static Analysis still has plenty to catch. In an earlier article, we have discussed how even Rust’s famous memory safety claim is misleading, and that Static Analysis helps to avoid run-time surprises.

Summary

Type safety bugs are everywhere: often implicit, sometimes explicit, and your compiler will not prevent any possible error. Static Analysis traces every one of them across your entire code base, including the legacy code nobody remembers writing. For safety-critical software, MISRA C has direct rules for this, and for stronger guarantees, Formal Methods can prove their absence entirely.

If you work with code and want to start today: enable the strictest compiler warnings, then run a type-aware Static Analysis pass, and you will be surprised what you find. If you influence your team, share this article, because most developers underestimate the problem and that is exactly why the bugs persist. If you manage a project, remember that one missed implicit cast cost the Mars Climate Orbiter $327 million, and budget for the analysis tool before the next overflow finds you.