Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91054 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91584 invoked from network); 2 Feb 2016 01:09:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2016 01:09:11 -0000 X-Host-Fingerprint: 94.13.91.147 unknown Received: from [94.13.91.147] ([94.13.91.147:4670] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C7/00-25412-6B100B65 for ; Mon, 01 Feb 2016 20:09:10 -0500 Message-ID: To: internals@lists.php.net References: <55.70.56702.FD2E7A65@pb1.pair.com> Date: Tue, 2 Feb 2016 01:09:06 +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: <55.70.56702.FD2E7A65@pb1.pair.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 94.13.91.147 Subject: Re: [RFC] Warn about invalid strings in arithmetic (moving back todiscussion) From: ajf@ajf.me (Andrea Faulds) Hi everyone, 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. Thanks. -- Andrea Faulds https://ajf.me/