Almost Always Unsigned

#1

Post by gavide » Wed, Jul 08, 2026, 7:35 PM UTC

Almost Always Unsigned
graphitemaster.github.io

Re: Almost Always Unsigned

#2

Post by pmarreck » Wed, Jul 08, 2026, 10:10 PM UTC

Related: I have a variable integer length encoding scheme that beats out LEB128, Protobuf, varint and ASN.1 while also encoding/declaring endianness (but notably, leaving signage information up to the application): https://github.com/pmarreck/BLIP

Re: Almost Always Unsigned

#3

Post by dataflow » Wed, Jul 08, 2026, 10:12 PM UTC

> for (size_t i = size - 1; i Erm... just because you can, doesn't mean you should.

Also, what if you want to go down to something other than 0?

Re: Almost Always Unsigned

#4

Post by scared_together » Wed, Jul 08, 2026, 10:14 PM UTC

There was a related article from the other side of the debate a while back: https://news.ycombinator.com/item?id=47989154

It’s pretty sad that after all these years, dealing with fixed size integers is still so complicated. Yes, many of the problems are specific to low level languages with undefined behaviour and numeric for loops. But the issue of subtracting two numbers and possibly having an underflow is both common and a bit absurd.

The code in the article for “safely” calculating the difference of two unsigned numbers, which is simpler than the equivalent for signed integers, is this little ritual:

> delta = max(x, y) - min(x, y);

Seriously??? Two function calls just for the difference of two numbers??

Why can’t such “safe” operations have some of the sweet syntactic sugar, and the underflow-rampant “ordinary” operations have the bitter medicine of ritual?

Re: Almost Always Unsigned

#5

Post by tialaramex » Wed, Jul 08, 2026, 10:18 PM UTC

Should be (2022) apparently - surely if HN can automatically screw up titles for various reasons, we can have it add dates automatically [and sometimes get those wrong] too? DanG ?

> for instance C and C++ leave signed integer wrap undefined

I'm pretty sure the way to write what was meant here is "C and C++ leave signed integer overflow undefined". Wrapping would be a definite choice. Overflow is the situation we're considering, not a particular outcome to choose so that is what's undefined.

The confusion gets worse later when it insists that just like in C or C++ these three Rust expressions will produce invalid results because of LLVM:

    x / 0
    INT_MIN / -1
    INT_MAX % -1
    INT_MAX - INT_MIN

Assuming we defined INT_MAX and INT_MIN as say i32::MAX and i32::MIN (or whichever signed type you prefer) of course what these actually do in Rust is just panic. If you write this in a context where it'll be evaluated at compile time, your compilation fails. That's not "invalid" in any sense I understand.

It mentions Odin too, I know less about Odin but I believe it too will reject this nonsense, on Godbolt it seems to either SIGILL (for zero) or SIGFPE (for other impossible operations)

Edited: Apparently I copy-pasted wrong? Some of those invalid expressions were not as written on the blog post but are now hopefully fixed. They are, of course, still not invalid in Rust, some panic because they aren't valid questions (like dividing by zero), others are fine - neither case is a problem.

Re: Almost Always Unsigned

#6

Post by theokrueger » Wed, Jul 08, 2026, 10:23 PM UTC

[dead]

Re: Almost Always Unsigned

#7

Post by tialaramex » Wed, Jul 08, 2026, 10:26 PM UTC

scared_together wrote: post #4

There was a related article from the other side of the debate a while back: https://news.ycombinator.com/item?id=47989154 It’s pretty sad that after all these years, dealing with fixed size integers is still so complicated. Yes, many of the problems are specific to low level languages with undefined behaviour and numeric for loops. But the issue of subtracting two numbers and possibly having an underflow is both comm…

I mean, Rust calls this function you want abs_diff

    let a = 1234_u32;
    let b = 5678_u32;
    let c = a.abs_diff(b); // Or equivalently u32::abs_diff(a, b);

Some languages hate offering convenience functions, in particular in a language like C or one of the would-be C-replacements, those functions just clog up the same namespace as everything else, so having 100 intrinsic arithmetic functions for integers feels disproportionate. The C-like languages, even those which do have methods, often forbid methods on their "built-in" or "core" types like integers so they can't do what Rust did here.

Edited: tweaked language

Re: Almost Always Unsigned

#8

Post by theokrueger » Wed, Jul 08, 2026, 10:28 PM UTC

dataflow wrote: post #3

> for (size_t i = size - 1; i Erm... just because you can, doesn't mean you should. Also, what if you want to go down to something other than 0?

[dead]

Re: Almost Always Unsigned

#9

Post by dataflown » Wed, Jul 08, 2026, 10:41 PM UTC

Stroustrup recommends int over unsigned. Dijkstra recommends int over unsigned. Google coding guidelines recommend int over unsigned.

Blogger recommends unsigned over int.

Tough choice.

Re: Almost Always Unsigned

#10

Post by gumby » Wed, Jul 08, 2026, 10:52 PM UTC

tialaramex wrote: post #5

Should be (2022) apparently - surely if HN can automatically screw up titles for various reasons, we can have it add dates automatically [and sometimes get those wrong] too? DanG ? > for instance C and C++ leave signed integer wrap undefined I'm pretty sure the way to write what was meant here is "C and C++ leave signed integer overflow undefined". Wrapping would be a definite choice. Overflow is the situation we're…

> for instance C and C++ leave signed integer wrap undefined

Not in C++29, and I think the big 3 compilers (gcc, clang, MS) will have squashed this long before that version is officially approved.