Hacker News Reader

Comment by up2isomorphism | Hacker News Reader

These examples do look scary. However, in my 16 years of experience of mostly writing In C, I have never found a single chance that I need to actually use the expressions that I got the answers wrong.

Never mix unsigned and signed integer comparison unless you know exactly what you are doing.

And never do arithmetic on boundaries definitions like INT_MAX, they are boundaries , why you need to compute a derived value on boundaries?

If you do not need arithmetic behavior, do not use signed integer, use unsigned. Because computer does not understand sign, so if you do not need a sign, do not use it.

You do not need to be a language committee member to write C , you just need to understand the reason behind its design.

View on HN

The problem is that for unsigned one of the boundaries is 0, which is an extremely common number - there isn't a couple months where I don't find a bug due to a size-1 somewhere

Subtraction would presumably fall under the arithmetic behavior that OP was talking about.

Maybe. But subtraction is also perfectly well defined for unsigned ints in C.

If you wanted to be extremely careful, you might pass unsigned ints into a function by copy, and cast it as a signed int to perform arithmetic, then do a boundary check before returning a result to be assigned back to an unsigned integer.

The unsignedness of the integer lets readers of the code know that it's a constant of some kind, and that comparisons should be performed with care. Normally, when I've worked with C (fairly limited), unsigned numbers normally get used as flags for bitwise comparisons. Sometimes your flags may have a partial ordering defined on them (so a sense of flag A being 'smaller' than flag B), so you might need some arithmetic to do those checks you need to be explicitly careful with the boundary checks though.

> And never do arithmetic on boundaries definitions like INT_MAX, they are boundaries

I'd argue something stronger: if you care about boundaries like INT_MAX, you should never be comparing them using your regular comparison tools. I.e., even though there are correct ways to compute whether x + 1 will overflow, don't bother trying to do that and instead always use __builtin_add_overflow since you can't fuck it up. Trying to do these sorts of edge checks are incredibly hard and it has lead to numerous security vulnerabilities due to checks being optimized out. The builtins do exactly what they say and you don't have to worry about UB blowing your foot off.

> If you do not need arithmetic behavior, do not use signed integer, use unsigned. Because computer does not understand sign, so if you do not need a sign, do not use it.

That's interesting. In my career (embedded development) I've learned to do the opposite. Always use signed unless you have a reason not to. Even if a value can't naturally be negative, use signed. Use unsigned only if you need the extra bit, or if you're doing bitwise operations.

> Because computer does not understand sign

Computers understand signs just fine, we're long past the days of the 6502 N-flag being a glorified bit 7 check. All CPUs have signed instructions.

> That's interesting. In my career (embedded development) I've learned to do the opposite. Always use signed unless you have a reason not to. Even if a value can't naturally be negative, use signed. Use unsigned only if you need the extra bit, or if you're doing bitwise operations.

In this case, since you make sure that the extra size gained by unsigned is not important to you all, then you can also go with signed by default. Basically it is the tradeoff between 1. robust in majority of the use cases 2. capability to do signed arithmetic 3. additional positive integer range. As long as you make a consistent selection and be mindful when you are in the danger zone, it can be handled.

> Always use signed unless you have a reason not to. Even if a value can't naturally be negative, use signed.

Can you elaborate on what benefits this approach has? I would feel that, especially when a number cannot be negative, unsigned integers seem like a proper representation of the data?

A big problem is that C doesn't make you stick to the representation.

If you accidentally subtract and go into 'negative' numbers, using an unsigned in C will just happily give you the wrong answer.

Now in something like Haskell, it's much more robust advice to make invalid states unrepresentable. But C's compiler and runtime don't typically help you, when you are trying to break your representation.

A couple of things I can think of off the top of my head: Since the compiler knows that certain things are UB using signed offers better (often significantly better) optimization opportunities then using unsigned. Plus, you get to use UBSan to detect bad code.

Here is an example: https://wesmckinney.com/blog/avoid-unsigned-integers/

It's not always obvious that you're mixing signed and unsigned, though.

I think the biggest source of these kinds of bugs is because size_t is unsigned but ptrdiff_t is signed. So the moment you mix pointer subtraction with sizeof, footguns abound.

Is it your experience that there are many projects where you can reliably say some variable will never need arithmetic behavior?

I don't have 16 years of experience writing C, but

> If you do not need arithmetic behavior, do not use signed integer, use unsigned

does seem in a roundabout way to match the advice that I've gotten from other folks -- usually stick to signed (because you never know if somebody is going to want to use an integer in, say, a downwards loop). Your comment just seems to highlight the less usual case, where you can be sure that nobody will ever need that arithmetic behavior... maybe it depends on the type of applications, though.

It always depends on the area of focus. You can also consistently choose the default int type to signed while being fully aware of you lose half range but gain signed integer arithmetic. For me I am mostly doing system and networking so I tends to to unsigned. The key is to choose a consistent default while aware of that you are in a non-intuitive zone when that default type puts you in.

The compiler will also warn about these cases where you better be explicit to avoid undesired behavior.

Reply on news.ycombinator.com