Unsigned Sizes: A Five Year Mistake

Docs Examples Download Discord Blog More Github Support us The C3 Blog Unsigned sizes: a five year mistake 2026-05-02 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. 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!{ ... }= 0; x--) // Infinte loop!{ ... }"> In fact, that bug is so easy to run into that C3 explicitly rejects x >= 0 for unsigned types outside of macros. uint a = 0;int b = -1; if (a > b) { ... } b) { ... }"> In C, both will promote to unsigned, turning b into a huge unsigned value, causing the comparison to fail. For this reason, C3 implemented safe unsigned/signed comparisons that wouldn’t convert both sides and be safe regardless. C, of course, allows implicit conversions between unsigned and signed. While this is a source of bugs, I felt that with some safety measures, it could mostly be kept. It’s easy to think that the bugs above are just unrelated quirks. The loop that never terminates, the broken comparison, the conversions that need to be fixed just-so… they all stem from one earlier decision: that unsigned should be the default for sizes. Most of this post is really about that decision. You might reasonably ask “but why not just require that signed/unsigned conversion is explicit?”. The reason, it turns out, lies with unsigned sizes. If sizes are unsigned, like in C, C++, Rust and Zig – then it follows that anything involving indexing into data will need to either be all unsigned or require casts. With C’s loose semantics, the problem is largely swept under the rug, but for Rust it meant that you’d regularly need to cast back and forth when dealing with sizes. There are two approaches to casts: one is to liberally sprinkle them all over the codebase with the idea that “it’s an explicit conversion, so it’s obvious what happens”. The other is to minimize casts, only using them to signal that something out of the ordinary is happening: “here be dragons”. The former is easier to define, but has the downside of essentially “silencing warnings”. Let’s say the code was originally written to cast an u16 to u32, but later the variable type changes from u16 to u64 and the cast is now actually silently truncating things. Here we have casts becoming a sort of “silence all warnings”. The main idea of “it’s an explicit conversion” is also undermined by the practice of just putting in casts mechanically where the compiler says they’re needed, rather than trying to actually examine every case. On the other hand, minimizing casts is more challenging: rules are needed to correctly allow “safe” implicit casts, while requiring casts for what’s unsafe. C3 takes the second approach: casts should mean something, but why did it allow unsigned -> signed? Isn’t that unsafe? It turns out that as long as you only use addition, subtraction and multiplication it’s mostly quite safe if signed integers are 2s complement. And given that the conversions would need to happen often (remember: unsigned sizes!), the trade-off to make it implicit was natural. C3 has largely kept the current conversion semantics since 2021, and had been working reasonably well without triggering any serious undesirable semantics for 5 years, until an innocent question about “(foo + a) % 2” turned those assumptions on its head. In order to remove footguns, C3 had picked “int + uint” to promote to “int” instead of unsigned. This made a lot more cases silently signed, which tended to be the correct thing in most cases. But what if we do (foo + a) % 2 and “foo” here happens to be over INT_MAX? Suddenly we get incomprehensible results! The right answer being (foo + a) % 2U instead. This was an unacceptable problem. Not because it was hard to fix, but because it was so surprising. Almost everywhere else you could simply ignore if there was an underlying conversion to signed or not – it just worked. But / and %? Here’s where the solution broke down. And because it “just worked” everywhere, it was fairly opaque what subexpression was signed or unsigned. The convenience made this minor issue into a big one. The immediate reaction to this was to patch it: just issue an error on doing “unsigned / signed” and “unsigned % signed”, but more issues were lurking in the shadows. If you write a ring buffer, how do you make sure that calculating offsets are wrapping? index = (start + offset) % length; This works as long as offset is positive. What about n

Unsigned Sizes: A Five Year Mistake

Key takeaways

Also covered by

Unsigned Sizes: A Five Year Mistake

Key takeaways

Also covered by

More in computer-science