Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25032
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <00cd01c6b21e$c3956a30$0201a8c0@pc1>
To: <internals@lists.php.net>, "Michael Wallner" <mike@php.net>
References: <00c601c6b095$a1a2e220$0201a8c0@pc1> <010601c6b169$225b9eb0$0201a8c0@pc1> <6E.DD.23194.071B8C44@pb1.pair.com> <016401c6b17e$027908c0$0201a8c0@pc1> <19.E0.23194.CE2C8C44@pb1.pair.com>
Date: Fri, 28 Jul 2006 03:21:02 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] dec*(), *dec(), base_convert() and negative numbers
From: php_lists@realplain.com ("Matt W")

Hi,

More thoughts...

I forgot to say last time that the manual doesn't mention the dec*()
parameter being treated as unsigned.  The *printf() specifiers b/o/x/X
already do this (although the manual doesn't say that either, only for %u).

After looking through the comments for dechex(), there's another thing: 32-
vs 64-bit.  On a 64-bit system, I think dechex(-123) would currently return
ffffffffffffff85, which when reversed on my system gives

php -d precision=20 -r "var_dump(hexdec('ffffffffffffff85'));"
float(18446744073709552000)

Are you saying, Michael, that the negative behavior should be left as-is for
people to see "how the number is stored by the computer?"  I think just
using the *printf() specifiers would better.  IMO, the dec*() and *dec()
functions should work the same as the corresponding to/from base with
base_convert() (absolute value), and vice-versa.

BTW, can base_convert() simply return an actual number instead of a string
when tobase=10?  Again, to be the same as *dec() and avoid conversion to
string if it's just going to be used in numeric context.


Matt


----- Original Message -----
From: "Michael Wallner"
Sent: Thursday, July 27, 2006


> Matt W wrote:
>
> > 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. :-))
>
> For your computer 0xffffff85 is -123 and 4294967173.  It's just how
> you look on it.
>
> > 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.
>
> No way. Why should hexdec(dechex(-123)) return +123?
>
> --
> Michael