|
|
Posted by fritz-bayer@web.de on 09/28/68 11:41
Oli Filth wrote:
> fritz-bayer@web.de said the following on 05/03/2006 12:33:
> > Oli Filth wrote:
> >> fritz-bayer@web.de said the following on 05/03/2006 11:39:
> >>> Tim Roberts wrote:
> >>>> PHP handles the overflow by throwing away the upper bits, leaving you with
> >>>> only the bottom 32 bits of the converted value. Perl handles the overflow
> >>>> by "pegging"; it returns 2^32-1, or 4,294,967,295. That value happens to
> >>>> have all 32 bit set, so the bitwise "and" returns the second value.
> >>>>
> >>>> If you need to handle integers larger than 32-bits in Perl, you can use the
> >>>> Math::BigInt module to do that.
> >>> Thanks Tim! Any ideas how I could emulate the overflow, so that I get
> >>> the same overflow behaviour in perl, maybe by writting a function for
> >>> it?!
> >>
> >> Why would you want to do this? Either way, you're not going to get the
> >> "correct" answer (in terms of mathematically correct).
> >>
> >
> > because I have to port the the following function including the
> > overflow behaviour from php to perl:
> >
> > //unsigned shift right
> > function fillWithZeroes($a, $b)
> > {
> > $z = hexdec(80000000);
> > if ($z & $a)
> > {
> > $a = ($a>>1);
> > $a &= (~$z);
> > $a |= 0x40000000;
> > $a = ($a>>($b-1));
> > }
> > else
> > {
> > $a = ($a>>$b);
> > }
> > return $a;
> > }
>
> Why would you be concerned about behaviour in out-of-range input
> conditions, as they're technically meaningless, and wouldn't be
> relied-upon except in the most bizarre situations? What's more, if you
> did make your Perl function consistent with PHP behaviour, it would then
> be inconsistent with the rest of Perl's behaviour.
>
> Anyway, I don't think the PHP behaviour Tim describes is consistent.
> For instance, try this in PHP:
>
> $a = 5543039444;
> $b = $a * 10000000000;
>
> echo $a . " => " . intval($a) . "\n";
> echo $b . " => " . intval($b) . "\n";
>
> PHP is clearly not just converting the floats to fully-represented
> integers and retaining only the 32 LSBs.
>
> --
> Oli
Well, I guess the program I'm porting relies on this strange behaviour.
That's for sure. I did not write it. I'm just trying to port it. Could
it be that php ocde above will convert those numbers to unsigned ints
so that no overflow takes place?!
[Back to original message]
|