Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91082
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <EC.30.03110.A5E74B65@pb1.pair.com>
To: internals@lists.php.net
References: <55.70.56702.FD2E7A65@pb1.pair.com>
 <C7.00.25412.6B100B65@pb1.pair.com>
Date: Fri, 5 Feb 2016 10:49:56 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0)
 Gecko/20100101 Firefox/42.0 SeaMonkey/2.39
MIME-Version: 1.0
In-Reply-To: <C7.00.25412.6B100B65@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [RFC] Warn about invalid strings in arithmetic (moving
 backtodiscussion)
From: ajf@ajf.me (Andrea Faulds)

Hi again,

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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Anyway, please tell me your thoughts.

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.

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.

Thanks.

-- 
Andrea Faulds
https://ajf.me/