Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:75528 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26934 invoked from network); 15 Jul 2014 07:06:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 15 Jul 2014 07:06:28 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.214 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.214 mail4-2.serversure.net Linux 2.6 Received: from [217.147.176.214] ([217.147.176.214:57717] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A0/F6-15121-DE2D4C35 for ; Tue, 15 Jul 2014 03:06:27 -0400 Received: (qmail 16240 invoked by uid 89); 15 Jul 2014 07:06:15 -0000 Received: by simscan 1.3.1 ppid: 16234, pid: 16237, t: 0.0740s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO ?10.0.0.8?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 15 Jul 2014 07:06:15 -0000 Message-ID: <53C4D2E7.9050706@lsces.co.uk> Date: Tue, 15 Jul 2014 08:06:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: internals@lists.php.net References: <7646A8D1-69A2-4255-B048-D3B9F28B422F@ajf.me> <53C47CA2.4050306@sugarcrm.com> <714C2E5E-A321-4993-9CFB-F7DFAC45C532@ajf.me> <53C4B955.5060401@sugarcrm.com> In-Reply-To: <53C4B955.5060401@sugarcrm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] intdiv() From: lester@lsces.co.uk (Lester Caine) On 15/07/14 06:17, Stas Malyshev wrote: >> Both of those are likely not to be installed on most systems. Why do > Why not? bcmath is in core since forever and has no external > requirements, gmp builds practically everywhere too. AFAIR all distros > have it. Taking this in isolation is wrong ... It is essentially linked up with all of the discussion on '64bit' processing. What seems to be ignored so far is the simple 'bigint' value. Limiting 32 bit systems to only support 32 bit integers may be the easy solution, but bigint is an essential element of most database type sets these days, so should be supported transparently. If a primary key is provided as part of a database result set, then do we really want the situation where some installs fall over with an overflow of that key on 32 bit systems? Having to use a secondary level function exclusively simply because the core processing gets it wrong is another mistake? Certainly it's not going to be easy to handle, and may not even be practical? But even the discussion on 'type hinting' seems to ignore the range problem where a 64bit value may be required but the installation on4y supports 32bit integers. Currently the value simply works with the string version ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk