Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:43371 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26352 invoked from network); 16 Mar 2009 18:00:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 Mar 2009 18:00:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=php_lists@realplain.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=php_lists@realplain.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain realplain.com from 209.151.69.1 cause and error) X-PHP-List-Original-Sender: php_lists@realplain.com X-Host-Fingerprint: 209.151.69.1 liberty.vosn.net Linux 2.4/2.6 Received: from [209.151.69.1] ([209.151.69.1:49860] helo=liberty.vosn.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A7/47-24423-1D39EB94 for ; Mon, 16 Mar 2009 13:00:50 -0500 Received: from 72-161-148-24.dyn.centurytel.net ([72.161.148.24]:61545 helo=pc1) by liberty.vosn.net with smtp (Exim 4.69) (envelope-from ) id 1LjH7E-0005rW-P9; Mon, 16 Mar 2009 12:00:45 -0600 Message-ID: To: Cc: "Lukas Kahwe Smith" , =?iso-8859-1?Q?Johannes_Schl=FCter?= Date: Mon, 16 Mar 2009 13:00:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - liberty.vosn.net X-AntiAbuse: Original Domain - lists.php.net X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - realplain.com Subject: [PATCH] Extend bitwise and modulus operators on 32-bit platforms From: php_lists@realplain.com ("Matt Wilmas") Hi all, I changed the bitwise and modulus operator functions to [try to] make them more consistent with behavior on 64-bit platforms. By accepting double operands and, if necessary, returning a double, their usable range is greatly extended without running into overflow issues, etc. (Of course, at some point, double precision would be a problem, but that's not till... the trillion range/40-ish bits or so?) See also Bug #46579 (% integer overflow - no error message). That means anything like this previously only-64-bit code works as expected: var_dump(((1 << 40) | (1 << 36)) % (10000000000 >> 1)); > float(3231104512) Fairly straightforward changes after adding a couple macros... Adding zendi_convert_to_double() to the other zendi_* ones seemed to be the easiest way to handle things. And, am I right to assume that most all modern compilers have a 64-bit long type? If not, code is unchanged from before (same for 64-bit). This is mostly independent of whatever is done as far as general "double to long conversion," but it does take care of the orginal issue I had. :-) http://marc.info/?l=php-internals&m=120799720922202&w=2 Patches: http://realplain.com/php/64bit_operators.diff http://realplain.com/php/64bit_operators_5_3.diff What do you all think? Thanks, Matt