Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43091
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 209.151.69.1 cause and error)
Message-ID: <00d401c991cc$879c1980$0201a8c0@PC>
To: "internals Mailing List" <internals@lists.php.net>,
	"zoe" <zoe.slattery@googlemail.com>
Cc: "Moriyoshi Koizumi" <mozo@mozo.jp>,
	"Ilia Alshanetsky" <ilia@prohost.org>,
	"Dmitry Stogov" <dmitry@zend.com>
References: <cd1fb7540902120848l43abcc7i34d24426ca456107@mail.gmail.com>	 <cd1fb7540902121256vb5c27caoe3246abde1aa62fb@mail.gmail.com>	 <6D771262-F1BD-43B7-93FC-BF9D47D15F49@prohost.org> <cd1fb7540902140027q4506c64ft28c1f1be4e49ccbe@mail.gmail.com> <499BF0CF.3000108@googlemail.com>
Date: Wed, 18 Feb 2009 07:25:39 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Bug #46701
From: php_lists@realplain.com ("Matt Wilmas")

Hi Zoe, all,

----- Original Message -----
From: "zoe"
Sent: Wednesday, February 18, 2009

> Moriyoshi Koizumi wrote:
> > Please don't even think of backporting. This will definitely break a
> > lot of things, and this kind of thing must not be done in a minor
> > release.
> >
> >
> --snip--
>
> >>>> I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was
> >>>> changed by the fix for bug #42868, right?
> >>>> If so, this patch shouldn't be MFH'ed as the #42868 patch was not
> >>>> merged although I didn't remember any discussion on this.
> >>>>
> >>>> See also: http://marc.info/?l=php-internals&m=120799720922202&w=2
> >>>>
> >>>>
> Hey all
>
> I'm sorry - I should have replied to this before since I was responsible
> for raising #42868.  I didn't do a good job at explaining what the issue
> was in that bug, mainly because I didn't know what it was when I
> started. The central problem is that PHP's behaviour on casting double
> to int defaults to whatever the underlying C environment does. On
> Windows and Linux (all of the versions that I looked at) this turns out
> to be a simple truncation of the last 32 bits. Unfortunately the C
> behaviour is 'undefined' (Kernigan and Ritchie, page 197, A6.3). The
> issue that I found in #42868 was that on the Mac the casting behaviour
> is completely different so many of the PHP tests failed. I believe that
> PHP should behave in a platform independent way - that is what the fix
> to #42868 achieves. It is also fair to say that any applications that
> depend on the overflow behaviour in PHP 5.2 cannot be guaranteed to run
> on any platform.

(I'm glad this change was reverted for 5.2...)

Anyway, like I said in my "5.3 todos" reply, I'll send a possible
DVAL_TO_LVAL, etc. solution (consistent/reliable overflow across platforms)
for consideration as soon as I can...  There are other inconsistencies and
behavior changes with the existing code, and it definitely doesn't behave in
a platform-independent way!  With the 4 versions of DVAL_...: old, 32 bit,
64 bit, 64 bit Windows (not sure why it's there; its longs are still 32
bit?), things I can think of:

- 64-bit Windows has no range limiting for casting, so it's free to overflow
like the old way...?  Other 64 bit limits the range to LONG_MAX/MIN.  32 bit
still casts between LONG_MAX and MAX_UNSIGNED_INT (ULONG_MAX-ish?), and,
presumably, it's supposed to overflow between those 2, but casting of the
out-of-range unsigned long is also "implementation-defined," so still cannot
be guaranteed.

- Conversion of INF/-INF: the old version and 64 bit Windows now will
convert them to 0.  32 bit and other 64 bit will convert them to
LONG_MAX/LONG_MIN.

- With zend_parse_parameters(), a numeric string that results in a double is
still converted using a simple (long) cast only.  (In my proposed changes, I
was going to add a new conversion specifier (simple few lines), like capital
'L', for functions that want/need to limit the long without overflow, like
lengths for some string functions that I *thought* was trying to be fixed
orginally.)

> Zoe

- Matt