Unsigned sizes: A five year mistake • Hacker News Board

Re: Unsigned sizes: A five year mistake

#151

Post by AlotOfReading » Mon, May 04, 2026, 7:53 PM UTC

nycticorax wrote: post #149

This is only somewhat related, but: Has there ever been a language that adopted IEEE-754-like semantics for integer types? (Yes, I know this would be slow without hardware support.) By this I mean adding valid values for (signed) ints to represent positive infinity, negative infinity, and not-a-number; then use these values as the results of overflow, underflow, and division by zero in the natural way. It just seems…

If you rename +/- Inf, that's what saturating arithmetic is. Very likely your language and hardware already supports it.

NaN is almost always a mistake, and adding it breaks the law of identity. You don't want it.

Re: Unsigned sizes: A five year mistake

#152

Post by uecker » Tue, May 05, 2026, 5:04 AM UTC

throwaway894345 wrote: post #150

uecker wrote: post #140

Earlier quoted context omitted.

Any reasonably good C code I ever worked with aimed to be warning free. But yes, if you can also make it an error. The flexibility is important though.

Regardless of whether you're "aiming for the code to be warning free" or telling the compiler to turn the warning into an error, you will make the implicit cast explicit and move on with your day. You've already said you should use your tools to flag these errors and that aiming to be warning free is a good thing, so I don't understand where we disagree, especially when making implicit casts explicit costs a single-d…

I was disagreeing with the statement that a "serious" language needs to have this hard-coded. think the C model where you can have the strictness if one wants to, but one can also opt-out is better.

Re: Unsigned sizes: A five year mistake

#153

Post by nycticorax » Tue, May 05, 2026, 4:32 PM UTC

AlotOfReading wrote: post #151

nycticorax wrote: post #149

This is only somewhat related, but: Has there ever been a language that adopted IEEE-754-like semantics for integer types? (Yes, I know this would be slow without hardware support.) By this I mean adding valid values for (signed) ints to represent positive infinity, negative infinity, and not-a-number; then use these values as the results of overflow, underflow, and division by zero in the natural way. It just seems…

If you rename +/- Inf, that's what saturating arithmetic is. Very likely your language and hardware already supports it. NaN is almost always a mistake, and adding it breaks the law of identity. You don't want it.

OK, I did not know about [saturation arithmetic](https://en.wikipedia.org/wiki/Saturation_arithmetic). Cool!

But I can't agree with the claim that "nan is almost always a mistake". Certainly if you're doing floating-point computation on large arrays, the last thing you want is e.g. for an error to be thrown in a elementwise division just because two corresponding elements both happen to be zero.

It's true that nan!=nan is one of the more 'controversial' parts of the standard, that possibly would have been decided the other way in a perfect world. But it was also a reasonable pragmatic decision at the time the standard was developed. See here: https://stackoverflow.com/a/1573715/1013442