|
|
Posted by fritz-bayer@web.de on 11/04/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?!
Navigation:
[Reply to this message]
|