8 ms·

Stupid question: why not unsigned int?

by Kretiini 10y ago

lloeki 10y ago
https://git.kernel.org/cgit/editors/uemacs/uemacs.git/commit/?id=8841922689769960fa074fbb053cb8507f2f3ed9 https://git.kernel.org/cgit/editors/uemacs/uemacs.git/commit...
- Symmetry 10y ago
  That's why this is an int rather than going to an unsigned short.
Symmetry 10y ago
You'll be comparing against a lot of other things like offsets that aren't naturally unsigned and having everything be of the same type just tends to reduce the number of potential corner cases. And it will be a bit faster for certain weird architectures since the overflow behavior of an unsigned is prescribed but signed overflow is undefined. But I really doubt anybody cares about that here.
jerf 10y ago
In my experience with languages that have both signed and unsigned ints, but have no overflow or underflow protection (which is pretty much all of them), you really want to use signed ints so that you can write assertions that numbers you expect to be positive are positive. You can't do that with unsigned ints since they are all by definition >= 0, so you always end up finding bugs where suddenly you've got MAX_INT - 34 floating around in your program horking things up with no easy ability to tell there's a problem early. A uint that actually threw an exception or something if you tried to underflow it would be useful, but most unsigned ints nowadays aren't all that useful.
- saurik 10y ago
  You still have to deal with wraparound all the way off the bottom of the negative end (which is absolutely possible: these kinds of massive additions and subtractions have been the basis of various exploits, often involving array math), and so you need to solve that problem anyway; but now you also have to constantly verify the number is positive, and it is extremely common to see checks in the wild which only verify that a sized index is less than some maximum :/.

8 ms·

Stupid question: why not unsigned int?

by Kretiini 10y ago

Stupid question: why not unsigned int?

lloeki 10y ago
https://git.kernel.org/cgit/editors/uemacs/uemacs.git/commit/?id=8841922689769960fa074fbb053cb8507f2f3ed9 https://git.kernel.org/cgit/editors/uemacs/uemacs.git/commit...
- Symmetry 10y ago
  That's why this is an int rather than going to an unsigned short.
Symmetry 10y ago
You'll be comparing against a lot of other things like offsets that aren't naturally unsigned and having everything be of the same type just tends to reduce the number of potential corner cases. And it will be a bit faster for certain weird architectures since the overflow behavior of an unsigned is prescribed but signed overflow is undefined. But I really doubt anybody cares about that here.
jerf 10y ago
In my experience with languages that have both signed and unsigned ints, but have no overflow or underflow protection (which is pretty much all of them), you really want to use signed ints so that you can write assertions that numbers you expect to be positive are positive. You can't do that with unsigned ints since they are all by definition >= 0, so you always end up finding bugs where suddenly you've got MAX_INT - 34 floating around in your program horking things up with no easy ability to tell there's a problem early. A uint that actually threw an exception or something if you tried to underflow it would be useful, but most unsigned ints nowadays aren't all that useful.
- saurik 10y ago
  You still have to deal with wraparound all the way off the bottom of the negative end (which is absolutely possible: these kinds of massive additions and subtractions have been the basis of various exploits, often involving array math), and so you need to solve that problem anyway; but now you also have to constantly verify the number is positive, and it is extremely common to see checks in the wild which only verify that a sized index is less than some maximum :/.