Unsigned Sizes: A Five Year Mistake
C3, a systems programming language, is transitioning from unsigned to signed integers as the default for sizes due to long-standing issues with unsigned types. Despite safety measures, subtle bugs related to arithmetic and type promotion, especially with division and modulo operations, revealed fundamental flaws in the unsigned default. The change addresses unexpected behaviors that arise when unsigned values interact with signed integers in common operations.
- ▪C3 has used unsigned types for sizes since its inception, but this choice has led to persistent bugs and unexpected behaviors.
- ▪A key issue arises in expressions like (foo + a) % 2 when large unsigned values exceed INT_MAX, causing incorrect signed promotions.
- ▪C3 previously promoted uint + int to int to reduce bugs, but this created silent failures in modulo and division operations.
- ▪The language now moves to signed-by-default to avoid the pervasive need for casts and to make type behavior more predictable.
- ▪Minimizing casts was a core design principle in C3, treating explicit conversions as indicators of exceptional cases.
Opening excerpt (first ~120 words) tap to expand
A quick note for readers who don’t follow C3: it’s a systems language in the C tradition. Specifics below are C3’s, but the tradeoffs apply to any language that has to pick a type for sizes and lengths. C3 is moving to signed by default, but why are we doing that? Isn’t unsigned more correct for sizes at least? Let’s try to answer that. The bugs of unsigned Since the early days, C3 has been using unsigned sizes. And while the name of the unsigned type changed over time – from “usize” to “usz” (after the unification with the uptrdiff type) – its position as the default has been unchallenged. However, unsigned has known pitfalls, the most well known being: for (uint x = 10; x >= 0; x--) // Infinte loop!{ ...
…
Excerpt limited to ~120 words for fair-use compliance. The full article is at Hacker News: Front Page.