Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:12736 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 74814 invoked by uid 1010); 11 Sep 2004 13:22:27 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 74788 invoked by uid 1007); 11 Sep 2004 13:22:26 -0000 To: internals@lists.php.net Message-ID: <4142FC13.60702@php.net> Date: Sat, 11 Sep 2004 15:22:27 +0200 User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040830) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Andi Gutmans References: <20040827122550.GC29943@redhat.com> In-Reply-To: <20040827122550.GC29943@redhat.com> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 82.169.231.157 Subject: Re: [PATCH] zend_operators DVAL_TO_LVAL fix From: abies@php.net (Ard Biesheuvel) 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