Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:12806
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20040914102557.035a2350@127.0.0.1>
Date: Tue, 14 Sep 2004 10:26:10 -0700
To: Ard Biesheuvel <abies@php.net>,internals@lists.php.net
In-Reply-To: <4142FC13.60702@php.net>
References: <20040827122550.GC29943@redhat.com>
 <20040827122550.GC29943@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] Re: [PATCH] zend_operators DVAL_TO_LVAL fix
From: andi@zend.com (Andi Gutmans)

Also <= LONG_MIN needed?
I guess yes?

At 03:22 PM 9/11/2004 +0200, Ard Biesheuvel wrote:
>Joe Orton wrote:
>>The DVAL_TO_LVAL macro is quite weird, I'm not sure exactly what it's
>>supposed to be doing but it probably isn't doing it. If the integral
>>part of d is outside the range of a long, the conversion has undefined
>>behaviour by the C99 standard; an explicit cast makes no difference
>>AFAICT.
>>GCC on IA64 does wierd things with this macro, though I think there's a
>>GCC bug involved there too.  This fixes the macro to have well-defined
>>behaviour for all values of 'd', and avoids triggering the GCC bug on
>>IA64 to boot (both PHP users on that platform will be happy):
>
>This probably has to do with the fact that on 64-bit systems, doubles lack 
>the accuracy to distinguish LONG_MAX from LONG_MAX +1. To be on the safe 
>side here, you might want to use >= LONG_MAX instead of > LONG_MAX, or 
>cast the other way around.
>
>--
>Ard
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php