> On 05 02 2016, at 11:49, Andrea Faulds <a...@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



Reply via email to