|
|
Posted by Dana Cartwright on 10/29/88 11:41
My e-mail address doesn't have a 2 in it.
<fritz-bayer@web.de> wrote in message
news:1141579228.695402.52300@i39g2000cwa.googlegroups.com...
> Thanks Dana and thanks to rest of the people who responded.
>
> I have debug both scripts an figured out that the program breaks, when
> it's processing the values
>
> a=5496229061, b=13
>
> The php script returns 146638 and the perl script 524287. So also the
> operation $a = ($a >> $b) yields different values in php and perl.
>
> Or could it be, that php is smart enough to create a unsigned integer,
> wheras perl does not and therefore an overflow occurs? Anyway here you
> have the possibiliy of an overflow depending on how $a is handled.
>
> Do you think >> differs in perl and php or is it an overflow problem?
Please remember that this function is ONLY VALID when fed a $a that fits
within a 32-bit signed integer. As has been pointed out, 5,496,229,061
doesn't fit within a 32-bit signed int (limit is 2,147,483,647). Nor does
it fit within an unsigned 32-bit int (limit is 4,294,967,295). It isn't a
question of whether PHP is using signed or unsigned arithmetic. It is
surely being stored as a float of some sort (which will vary from one
computer to another).
Therefore, you simply cannot pass it to this function and expect predictable
results. Your results will depend upon the nitty-gritty details of the
language, the computer you're on, the version of the software you're
using...in short, you cannot pass this function 5496229061 and ask
meaningful questions about the results. It's not an overflow problem. It
does not depend on how >> works. It has to do with how numbers are
represented in memory.
If you have software that is feeding 5496229061 to this function, then you
have a HUGE problem. Evidently the software depends upon the specific value
that this function HAPPENS TO RETURN when run on a CERTAIN HARDWARE PLATFORM
on a PARTICULAR VERSION OF PHP. Aside from the issue of porting it to perl,
I am certain that this software will break (in unpredictable ways) simply by
the passage of time, because if you try to run it on a different computer,
it will likely break. If you upgrade PHP, it will likely break. And so on
and so forth. This is a time bomb that will sooner or later detonate.
You cannot easily fix this problem by messing around with this function.
Your software is breaking the rules, and you are suffering the consequences.
You could study the floating point representation of 5,496,229,061 and see
if the results you are getting can be predicted from that (this should be
possible, since computers are not whimsical). You would need to look at the
PHP code that implements >> and see what it does with a floating point (this
is where open source is *really* handy). And you could try to force perl to
do its arithmetic the same way. And you could meticulously document the
resulting code. It should be possible to do. It's what I would do if this
were my problem to solve and I wasn't able to fix the real problem, which is
that some idiot wrote code that is passing bogus values to this function.
-Dana
Navigation:
[Reply to this message]
|