OT: PHP 32 bit numbers security issue

[Uri Even-Chen]

On Wed, Jan 5, 2011 at 21:35, Oleg Goldshmidt <pub at goldshmidt.org> wrote:
> Uri Even-Chen <uri at speedy.net> writes:
>
>>> A really great paper concerning floating point representation can
>>> be found at http://docs.sun.com/source/806-3568/ncg_goldberg.html -
>>>
>>> What Every Computer Scientist Should Know About Floating-Point
>>> Arithmetic
>>
>> It's a little too long for me to read.  Also, isn't there anything new
>> since March 1991?
>
> Actually, not very much if you seek understanding. Representing
> numbers inside computers is a pretty basic thing that does not change
> significantly that often.
>
> Having said that, the latest incarnation of IEEE754 standard was
> published in 2008 (want to read an IEEE standard instead of a
> paper?). AFAIK, IBM has HW support for "denormalized" decimals (see
> Goldberg's paper) in recent z and Power processors
> (http://speleotrove.com/decimal/). You can find papers describing
> implementation.
>
>> Speaking about numbers, I noticed that when programming in Java, I
>> don't get any exception when the expression I want to calculate
>> overflows the number representation.  For example if I calculate 10000
>> * 10000 * 10000, then I get some strange number without any exception.
>>  This is of course a serious bug.  Of course I can do 10000L * 10000L
>> * 10000L, or 10000.0 * 10000.0 * 10000.0, but I would expect the
>> compiler at least to throw an exception, or better - to use long
>> integers in this case.  This is related to what I previously wrote
>> about numbers - I think compliers and calculators should do their best
>> to represent numbers as accurate as possible and as big (or small) as
>> possible, without bothering the user or programmer with the bit-to-bit
>> details of the number representation.
>
> This is why recent versions of Java (and C#... oops, sorry) have
> BigDecimal - arbitrary precision decimal numbers. If you read
> Goldberg's paper you'll get a good idea what they are. Of course, it
> is implemented as a user class and not a basic type, and Java does not
> allow operator overloading, so even simple arithmetic expressions in
> your code look ugly and unwieldy[1]. In a more powerful language like
> C++ you can overload arithmetic (and other) operators and arbitrary
> precision numbers will look natural in your code.

Thank you.  I used quite a few programming languages, including C,
PHP, Java and MATLAB.  I know one can overcome such difficulties, by
defining your own class or array.  But I think programming languages
should be more friendly, and always convert numbers to the best
representation, or report overflow cases. In the past, speed and
memory were more important than today. Today, graphics and video take
a lot of resources, so mathematical calculations can be slower and
more accurate - multiplying two numbers with 1024 bits each is much
faster than what is used to be 20 or 30 years ago.  If one can
calculate the first million digits of e
[http://antwrp.gsfc.nasa.gov/htmltest/gifcity/e.1mil], then I don't
see any reason why not to use more accurate representation of numbers,
and compilers should do this automatically.  For example in PHP, every
number should be represented to 100% accuracy, at least when
representing rational numbers.  Only when calculating irrational
numbers one has to specify the accuracy of the calculation.

>
> If you know what you are doing, it is not terribly difficult
> (cf. http://www.docjar.com/html/api/java/math/BigDecimal.java.html).
> Others have done it though. E.g., AFAIK IBM's decNumber++
> (http://www.alphaworks.ibm.com/tech/decnumberplusplus) is a reference
> implementation of the proposed addition to the C++ standard (for C
> look for decNumber, http://speleotrove.com/decimal/decnumber.html,
> there is a link to code). You need to register to download the code, I
> think.
>
>> The size of the number (in bits) or speed are less important, what's
>> more important is the accuracy and size of the number.  At least
>> there should be an option, when calculating real numbers, to use
>> better accuracy than the floating point "double", which is only 64
>> bits long.  One should be able to select the number of bits used for
>> accuracy, and the number of bits of the exponent.  For example -
>> 1024 bits for accuracy + 32 bits for the exponent.
>
> You are on the right track, good thinking!
>
> [1] I have to deal with Java code using a custom implementation dating
>    from before BigDecimal was introduced in Java 5. The interface is
>    the same as the standard BigDecimal, so I can't blame the authors,
>    but boy, is it a pain to read!
>
> --
> Oleg Goldshmidt | pub at goldshmidt.org
>



Uri Even-Chen
Mobile Phone: +972-50-9007559
E-mail: uri at speedy.net
Website: http://www.speedy.net/