Re: [RFC] Warn about invalid strings in arithmetic (moving backtodiscussion)

From: Date: Fri, 05 Feb 2016 12:08:41 +0000
Subject: Re: [RFC] Warn about invalid strings in arithmetic (moving backtodiscussion)
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-91083@lists.php.net to get a copy of this message
> On 05 02 2016, at 11:49, Andrea Faulds <ajf@ajf.me> wrote: > > 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. To be honest, I had not even memorised intval() supports a base, but that we have base_convert(). I’d opt for dropping base convert support from intval(), but that’s obviously not possible, because PHP-7.1 is the target for this RFC. Cheers, Mike

« previous php.internals (#91083) next »