Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58687
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGovj_PaYW16t=o8wNJ3mQ_Zw2ueLtavnxuGSph=1wq5k=wxtA@mail.gmail.com>
References: <CAGovj_NgoDkFnPwz+i1m5dmHh_T_886KtyozRhJ4+GbuQ38y2A@mail.gmail.com>
	<CAAyV7nFhnDMuAZq6igeGE2dJ=PtFji1kpdUtquE08f+dqVzBBw@mail.gmail.com>
	<CAGovj_PaYW16t=o8wNJ3mQ_Zw2ueLtavnxuGSph=1wq5k=wxtA@mail.gmail.com>
Date: Tue, 6 Mar 2012 16:31:29 -0500
Message-ID: <CAAyV7nFEuiraBtq2ocD1FGZLp1AjwMq0rUEbJHoNZr921sX8jA@mail.gmail.com>
To: Michael Morris <dmgx.michael@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Config setting to force all math operations to
 pass through BCMath library.
From: ircmaxell@gmail.com (Anthony Ferrara)

>> But please don't add another ini setting. =A0Especially one where
>> *logic* can change depending on the setting. =A0I don't want a case
>> where pow(2, 65)-1 will return different answers depending on the ini.
>> =A0That's just asking for problems.
>
> I edited the RFC while you were sending this for clarification. This
> setting would only affect the math operators (+,/,*,-) mapping them to
> their bcmath equivalents. =A0Math functions like pow would not be
> affected.

Actually, I see that as even worse.  Why would 2 * 4 be possible to be
different from pow(2, 3)?  That doesn't really make sense (to me).  I
think if it was added, all of the math related extensions would need
to be (should be) updated as suits.  Otherwise it's just another
random inconsistency...

>>
>> Instead, perhaps a pythonic approach may be useful (storing as
>> int/float for small values, but auto-converting to arbitrary precision
>> if the int/float can't exactly represent what was
>> requested/computed)... =A0Just a thought to make it useful without the
>> ini complexity or performance hits.
>>
>> Although this will present a significant BC break (internally, zend
>> engine wise), so it would probably be limited to a major release
>> anyway...
>>
>
> With a setting there would be no BC break since, if you turn it on,
> presumably you want it on. =A0Also, for scripts where the author wasn't
> aware of the peril of floating point math the setting could actually
> fix their existing code.

When I said BC break, I'm talking about at the engine level.  So all
3pd code that hooks into the engine (PECL extensions mainly) would be
broken, as the structure of the ZVal would need to change to
accommodate the bignum representation...