Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65769 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30995 invoked from network); 11 Feb 2013 08:43:46 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Feb 2013 08:43:46 -0000 Authentication-Results: pb1.pair.com smtp.mail=remi@fedoraproject.org; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=remi@fedoraproject.org; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fedoraproject.org from 212.27.42.5 cause and error) X-PHP-List-Original-Sender: remi@fedoraproject.org X-Host-Fingerprint: 212.27.42.5 smtp5-g21.free.fr Linux 2.6 Received: from [212.27.42.5] ([212.27.42.5:43828] helo=smtp5-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id AE/21-22812-F3FA8115 for ; Mon, 11 Feb 2013 03:43:45 -0500 Received: from dixsept.famillecollet.com (unknown [82.241.130.121]) by smtp5-g21.free.fr (Postfix) with ESMTP id 73038D481BD for ; Mon, 11 Feb 2013 09:43:37 +0100 (CET) Message-ID: <5118AF38.609@fedoraproject.org> Date: Mon, 11 Feb 2013 09:43:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: PHP Internals References: <511666DE.8080809@fedoraproject.org> <51172819.4000806@sugarcrm.com> <51174790.8040805@fedoraproject.org> <511751C5.1020906@fedoraproject.org> <51175BDD.9040705@sugarcrm.com> <5117BA92.8080307@fedoraproject.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [PHP-DEV] double val to long val conversion issue From: remi@fedoraproject.org (Remi Collet) Le 10/02/2013 20:27, Gustavo Lopes a écrit : > Any reservations? Do we really want/need to change the current behavior. Cast from double, outside of integer range, result in a fix value. The only problem is that the value is not the same on all arch. x86_64 always return 0x8000... ppc64 returns LONG_MAX (0x7fff...) for signed value >= LONG_MAX LONG_MIN (0x8000...) for signed value <= LONG_MIN ULONG_MAX (0xffff...) for unsigned value >= ULONG_MAX NB. The current fix applied only fix LONG_MAX value. Cast for >= ULONG_MAX is not fixed. Note (my "very" personal opinion) I think ppc64 behavior is better as it preserve the sign of the result... ;) But Intel seems the "standard"... Remi.