Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91083
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.51 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0D43EB6F-03CF-4BA0-B406-E42B26EF6F6D"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
In-Reply-To: <EC.30.03110.A5E74B65@pb1.pair.com>
Date: Fri, 5 Feb 2016 13:08:41 +0100
Cc: internals@lists.php.net
Message-ID: <0EC3D394-F475-42EF-B5DA-2393A88E1797@php.net>
References: <55.70.56702.FD2E7A65@pb1.pair.com> <C7.00.25412.6B100B65@pb1.pair.com> <EC.30.03110.A5E74B65@pb1.pair.com>
To: Andrea Faulds <ajf@ajf.me>
Subject: Re: [PHP-DEV] [RFC] Warn about invalid strings in arithmetic (moving backtodiscussion)
From: mike@php.net (Michael Wallner)

--Apple-Mail=_0D43EB6F-03CF-4BA0-B406-E42B26EF6F6D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


> On 05 02 2016, at 11:49, Andrea Faulds <ajf@ajf.me> wrote:
>=20
> Hi again,
>=20
> Andrea Faulds wrote:
>> There is one unresolved issue with the current patch that the RFC
>> doesn't address, so I'll ask about it here.
>>=20
>> As part of supporting exponent notation in all remaining integer
>> operations (casts, operators), I would like to have intval() support =
it,
>> to match the `(int)` cast.
>>=20
>> For strings, intval() doesn't use the normal zval-to-long conversion
>> functions (zval_get_long/convert_to_long), but instead uses strtol
>> directly. This is so it can support multiple bases, e.g. intval("10",
>> 12) results in 12.
>>=20
>> In order for intval() to support exponent notation, I'd have to =
change
>> it to now call zval_get_long, but that function doesn't support
>> non-decimal bases, nor does is_numeric_string_ex, which underlies it.
>>=20
>> So, we'd either have to make intval() only support exponent notation =
for
>> base 10, an unfortunate inconsistency, or we could not touch =
intval(),
>> but then intval($a, 10) would no longer act the same as (int)$a.
>>=20
>> I'm leaning towards the first choice, but I'd like to hear what the
>> mailing list thinks. Either way we have a new inconsistency. But =
then,
>> intval() has unfortunate behaviour with its base parameter anyway, in
>> that ignores the base for non-string input. That means that =
intval(123,
>> 8) and intval("123", 8) aren't equivalent, a violation of weak =
typing.
>>=20
>> Anyway, please tell me your thoughts.
>=20
> There hasn't been any response to this so far on the mailing list, =
unfortunately. In discussions I've had elsewhere, making it apply to =
intval() but only for base 10 has seemed to make sense. Both ways result =
in inconsistency.
>=20
> So, I've updated the RFC to clarify that it does apply to intval(), =
but only where $base is 10, and also to clarify that settype() should be =
affected.


To be honest, I had not even memorised intval() supports a base, but =
that we have base_convert().

I=92d opt for dropping base convert support from intval(), but that=92s =
obviously not possible, because PHP-7.1 is the target for this RFC.

Cheers,
Mike




--Apple-Mail=_0D43EB6F-03CF-4BA0-B406-E42B26EF6F6D--