Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Almost Always Unsigned

graphitemaster.github.io

Post reply on HN
Print view View original

21–30 of 103 posts

Re: Almost Always Unsigned

#21

Post by Groxx »

cpeterso wrote: post #13

There was a golang proposal to change Go's default int type to arbitrary precision big int. It would avoid overflow bugs, but the proposal was closed (after eight years) due to concerns about compatibility reading serialized data and performance. https://github.com/golang/go/issues/19623

as much as I'm not really a fan of Go, and I would love to spend some time in a language that defaults to unsigned ints by default to see just how pleasant or painful it really is, I do think Go makes a reasonable tradeoff here.

signed ints are rather obviously the majority decision, so that default is defensible, and their const / compile-time math is arbitrary precision. so as long as you can describe your math as either wholly const or can move all overflow-risky stuff into a const equation, you're good - Go's compiler will fail if it exceeds the bounds of whatever number you try to cast it to (implicitly or explicitly).

ignoring fun with float rounding, of course.

Re: Almost Always Unsigned

#22

Post by nulltrace »

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?

That loop reads like a bug to anyone who hasn't memorized the wrapping rules. while (i-- > 0) on a signed index does the same thing.

Re: Almost Always Unsigned

#24

Post by Groxx »

nazcan wrote: post #20
StellarScience wrote: post #11

Earlier quoted context omitted.

I liked how the discussion of 'delta = x - y' moved right on to how really you usually want delta = abs(x - y), so let's talk about that instead... Even beyond Stroustrup, Dijkstra, and Google, this whole panel of C++ luminaries agrees to prefer signed types and explains pretty clearly why: - 12:12-13:08 - https://www.youtube.com/watch?v=Puio5dly9N8#t=12m12s - 42:40-45:26 - https://www.youtube.com/watch?v=Puio5dly9N8…

Thanks for the excerpts! I was trying to understand the reasoning, which seem to just be in the 2nd excerpt: - The rules of signed/unsigned are complicated and there is too much auto-conversion - does that mean languages that make this more explicit means this is fine? It just seems ideal to have stronger typing. - It is mentioned that you can initialized an unsigned int to "-2" - but that presumably could also be fi…

that argument (and many others) also round to essentially "implicit imprecise integer casting is surprising but we do it anyway" which is... perhaps the actual problem???

I've made lints for Go that simply disallow implicit number casting, and omfg the (real, occurring but unnoticed) bugs it found. those kinds of lints are trivial to build, you can just stop doing it. forcing visible casts made many of these problematic patterns extremely suspicious at a glance, catching issues at review time far more easily.

Re: Almost Always Unsigned

#25

Post by leecommamichael »

dataflown wrote: post #9

Stroustrup recommends int over unsigned. Dijkstra recommends int over unsigned. Google coding guidelines recommend int over unsigned. Blogger recommends unsigned over int. Tough choice.

Commenter implies authority dictates strategy.

We should be engaging with the article's content.

Re: Almost Always Unsigned

#26

Post by leecommamichael »

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…

https://odin-lang.org/docs/overview/#integer-overflow

> For signed integers, the operations +, -, *, /, and << may legally overflow and the resulting value exists and is deterministically defined by the signed integer representation. Overflow does not cause a runtime panic. A compiler may not optimize code under the assumption that overflow does not occur. For instance, x < x+1 may not be assumed to be always true.

Re: Almost Always Unsigned

#28

Post by xyzzyz »

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…

For the stuff I do, I rarely use signed types. I find the example of finding difference between two numbers to be really silly. I don’t recall ever having to do anything like that, for a simple reason: I design my code so that I always know which number will be larger than the other.

Let’s actually talk more about this max - min example. Let’s say you calculated this delta. What is it useful for in your code? Typically, in real algorithms, what you want is to not only know the delta, but also which number is larger.

Re: Almost Always Unsigned

#29

Post by AlexClickHouse »

dataflown wrote: post #9

Stroustrup recommends int over unsigned. Dijkstra recommends int over unsigned. Google coding guidelines recommend int over unsigned. Blogger recommends unsigned over int. Tough choice.

ClickHouse code style recommends unsigned in every case when you don't need the sign: https://clickhouse.com/docs/development/style

Re: Almost Always Unsigned

#30

Post by a_t48 »

Groxx wrote: post #24
nazcan wrote: post #20

Earlier quoted context omitted.

Thanks for the excerpts! I was trying to understand the reasoning, which seem to just be in the 2nd excerpt: - The rules of signed/unsigned are complicated and there is too much auto-conversion - does that mean languages that make this more explicit means this is fine? It just seems ideal to have stronger typing. - It is mentioned that you can initialized an unsigned int to "-2" - but that presumably could also be fi…

that argument (and many others) also round to essentially "implicit imprecise integer casting is surprising but we do it anyway" which is... perhaps the actual problem??? I've made lints for Go that simply disallow implicit number casting, and omfg the (real, occurring but unnoticed) bugs it found. those kinds of lints are trivial to build, you can just stop doing it . forcing visible casts made many of these problem…

I believe there's ways to configure clang to flag dangerous implicit casts as well.
Post reply on HN