5 ms·

I would guess that nearly all code, period, is vulnerable to integer overflow issues. I don't think it makes sense to worry about this except in very special c

I would guess that nearly all code, period, is vulnerable to integer overflow issues. I don't think it makes sense to worry about this except in very special cases.

zvrba 13y ago
> I would guess that nearly all code, period, is vulnerable to integer overflow issues. Lack of checked integer arithmetic in some form is what I think is Java's biggest failure. Next to it is a lack of unsigned less/greater-than operator; it cannot be emulated easily with signed arithmetic. [There is unsigned right shift.] (.Net _does_ have checked arithmetic; at least as an option.)
AndrewBissell 13y ago
Having an array with more than about 1.2 billion elements is all that it would have taken to break the old binary search, and that's not all that uncommon anymore. Pure JavaScript code isn't vulnerable to integer overflow by virtue of not having any integer types, and I believe errors like this were the reason for leaving them out of the language.
- vbit 13y ago
  JavaScript numbers are just floats and susceptible to precision loss as well as overflow to Infinity, aren't they? In fact, if incremented repeatedly, 64-bit floats lose precision before 64-bit ints overflow.
  - AndrewBissell 13y ago
    Oh yes, floating point numbers have ALL SORTS of other issues. I was just stating the JS rationale for leaving ints out of the language, not saying I find it particularly convincing at all.
  - masklinn 13y ago
    > 64-bit floats lose precision before 64-bit ints overflow. More precisely, a 64 bit IEEE 754 ("double precision") has 53 bits worth of "integer"[0], which allows for 15 digits (and almost, but not quite, 16: it can encode 15.95 decimal digits) [0] even though only 52 bits are allocated to the fraction, because the fraction part has an implicit 53rd bit set to 1 outside of special values
- dsego 13y ago
  That wasn't the reason, the reason was to make the language simpler, with only one number type.
- yetanotherphd 13y ago
  But any system with such a large array would almost certainly be 64 bit by now.
jadyoyster 13y ago
How so? From [1] it would seem that Lisps (idiomatic ones at least), Python, Perl, Haskell and Ruby are all free from the possibility of integer overflow. That definitely doesn't sound like "nearly all code". [1] https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic
- Perseids 13y ago
  With Haskell I would not be so sure. There is the 'Integer' arbitrary size data type but what is mostly used is 'Int' for efficiency reasons afaik. Compiled as a 64 bit executable this should be a 64 bit integer though.
- yetanotherphd 13y ago
  In that case the language fixes the issue so the code is irrelevant. In languages where integer overflow is possible, my point still holds.

I would guess that nearly all code, period, is vulnerable to integer overflow issues. I don't think it makes sense to worry about this except in very special cases.

zvrba 13y ago

> I would guess that nearly all code, period, is vulnerable to integer overflow issues. Lack of checked integer arithmetic in some form is what I think is Java's biggest failure. Next to it is a lack of unsigned less/greater-than operator; it cannot be emulated easily with signed arithmetic. [There is unsigned right shift.] (.Net _does_ have checked arithmetic; at least as an option.)

AndrewBissell 13y ago

Having an array with more than about 1.2 billion elements is all that it would have taken to break the old binary search, and that's not all that uncommon anymore. Pure JavaScript code isn't vulnerable to integer overflow by virtue of not having any integer types, and I believe errors like this were the reason for leaving them out of the language.

vbit 13y ago
JavaScript numbers are just floats and susceptible to precision loss as well as overflow to Infinity, aren't they? In fact, if incremented repeatedly, 64-bit floats lose precision before 64-bit ints overflow.
- AndrewBissell 13y ago
  Oh yes, floating point numbers have ALL SORTS of other issues. I was just stating the JS rationale for leaving ints out of the language, not saying I find it particularly convincing at all.
- masklinn 13y ago
  > 64-bit floats lose precision before 64-bit ints overflow. More precisely, a 64 bit IEEE 754 ("double precision") has 53 bits worth of "integer"[0], which allows for 15 digits (and almost, but not quite, 16: it can encode 15.95 decimal digits) [0] even though only 52 bits are allocated to the fraction, because the fraction part has an implicit 53rd bit set to 1 outside of special values
dsego 13y ago
That wasn't the reason, the reason was to make the language simpler, with only one number type.
yetanotherphd 13y ago
But any system with such a large array would almost certainly be 64 bit by now.

jadyoyster 13y ago

How so? From [1] it would seem that Lisps (idiomatic ones at least), Python, Perl, Haskell and Ruby are all free from the possibility of integer overflow. That definitely doesn't sound like "nearly all code". [1] https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic

Perseids 13y ago
With Haskell I would not be so sure. There is the 'Integer' arbitrary size data type but what is mostly used is 'Int' for efficiency reasons afaik. Compiled as a 64 bit executable this should be a 64 bit integer though.
yetanotherphd 13y ago
In that case the language fixes the issue so the code is irrelevant. In languages where integer overflow is possible, my point still holds.