Hi Michael,
----- Original Message -----
From: "Michael Wallner"
> Matt W wrote:
> > Hi again,
> >
> [...]
>
> I don't see what you're trying to fix.
>
> $ cli -r 'var_dump((int)hexdec(dechex(-123)),
(int)(float)sprintf("%u",-123), (int)0xffffff85);'
> int(-123)
> int(-123)
> int(-123)
The main "fix" (upgrade) is to let the dec*() functions convert numbers >=
2^32. But I'm *wondering* whether *this* should be changed:
C:\math-old>php -r "var_dump(hexdec(dechex(-123)));"
float(4294967173)
Your (int) typecast changed that of course.
If the dec*() functions handle numbers whose absolute value is >= 2^32, how
is a negative double supposed to be handled? Absolute value, I assume. But
that's different than negative int handling now (internal long converted to
unsigned long). If double's were to be the same way, and there was an
unsigned double type, passing -5000000000 would result in an insanely huge
number after being made "unsigned" internally like now.
That's why I'm assuming negative numbers aren't "really" supported now (not
in any form with base_convert()), but it's simply a side effect of wanting
to handle *positive* numbers between LONG_MAX and ULONG_MAX. e.g. when
doing dechex(4294967173) that's a PHP double, but it gets converted to long
(becomes -123), and finally unsigned long (recovering 4294967173). IOW,
after convert_to_long() in dec*() it doesn't know if -123 or 4294967173 was
passed. Make sense? (Actually, it doesn't, that's my point. :-))
So after more thinking, I figure when upgrading dec*() to handle any number,
absolute value should be used (then int(123) would be returned in my
example). Unless the all the functions are changed to properly
accept/return negatives... I personally don't care either way on that.
> Regards,
> --
> Michael
Matt
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
