| 1 |
On Saturday, August 22, 2015 7:40:31 PM walt wrote: |
| 2 |
> On Sat, 22 Aug 2015 16:57:41 +0200 |
| 3 |
> hw <hw@×××××××××××××××××××××.de> wrote: |
| 4 |
> |
| 5 |
> > It is a recipe for disaster when you tell |
| 6 |
> > your computer to print something but it prints something else instead. |
| 7 |
> |
| 8 |
> The Android Stagefright exploit is a real-life example of exactly such a |
| 9 |
> disaster. |
| 10 |
|
| 11 |
That's an integer overflow which is a different thing. |
| 12 |
That's the same type of bug that brought down the Cluster spacecraft[1]. |
| 13 |
|
| 14 |
> The arithmetic comparison in Stagefright was written in C, not perl, |
| 15 |
> and compared integers instead of floats, but the underlying fault is |
| 16 |
> the same in each case: programming languages today assume that human |
| 17 |
> programmers think like machines. |
| 18 |
> |
| 19 |
> Until that fundamental flaw is eliminated from all programming |
| 20 |
> languages, the problem will not go away. That won't happen in my |
| 21 |
> lifetime, or yours. |
| 22 |
|
| 23 |
Neither integer overflows nor floating point's limited precission are flaws in |
| 24 |
programming languages. The flaws come when the languages are used improperly. |
| 25 |
|
| 26 |
A better way to think about floating point is that it's handled more like we |
| 27 |
handle numbers in our head. For example, if I ask you "how far you live from |
| 28 |
here?" you'll probably say something like "3 miles", not 3.003221 miles. |
| 29 |
Because at that scale the inaccuracy is acceptable. Likewise floating points |
| 30 |
can handle very large and very small numbers by doing the same. They trade |
| 31 |
between accuracy and range and they do it automagically. Consider that between |
| 32 |
1.000000001 and 1.000000002 there's infinity possible values so it would take |
| 33 |
inifinite memory to store it. |
| 34 |
|
| 35 |
|
| 36 |
1. https://en.wikipedia.org/wiki/Cluster_%28spacecraft%29 |
| 37 |
-- |
| 38 |
Fernando Rodriguez |
Archives