Pierre wrote:
> Hello,
>
> Note that I also answer your previous mail here :)
>
> On Fri, 11 Aug 2006 06:18:13 -0500
> [EMAIL PROTECTED] ("Matt W") wrote:
>
>> Hello again,
>>
>> I discovered a couple more things is_numeric... is causing problems
>> with (leading whitespace). I doubt any of the examples I've given
>> make sense to regular users who don't know what's happening behind
>> the scenes. Add these to the "wrong" list:
>>
>> is_numeric(' .123') // bool(false)
>
> this one should return true.
as Pierre mentions further down changing this behaviour could cause pots of
problems for existing code. from an enduser POV having is_numeric(' .123')
return true (and therefore having maths operations using ' .123' use that string
as if it was '.123' would be tantamount to doing:
$v = " .123";
$v = trim($v);
var_dump(is_numeric($v), ($v + 0));
In order to be able to move forward and allow for leading spaces in numeric
strings
maybe an ini setting could be used, one that defaults to false:
trim_numeric_strings_before_usage = 0;
such a setting if true would essentially trim space (like the trim() function
does)
form strings before they were checked (by is_numeric) and before being used in
calculations.
in php6 the default of this ini setting could be changed to true (which would
offer quite some time to check for possible unforeseen problems and eventually
in php7,8,9 the setting could dissappear entirely once the community is
satisfied
any/all problems have been dissipated.
I have no idea if this is feasable or desirable (I'm aware of the animosity
towards
new ini settings!) but it might offer a potential resolution between moving
forward
and protecting muppets like myself from 'strange behaviour' related to
autocasting of
numeric strings.
rgds,
Joche,
>
>> ' .123' + 0 // int(0)
>
> ' 0.123' is casted to 0, 0+0. But if the ' .123' is allowed, it should
> then result in 0.123+0, which is the correct behavior.
>
>
>> One more thing I was curious about as far as keeping things
>> consistent is with is_numeric... (and therefore
>> convert_scalar_to_number()), hex strings are allowed/work, but not
>> with convert_to_[long|double]().
>
> I did not check convert_* while fixing/enhancing filters, but I think
> there is a higher risk of breakages if you change these functions. We
> should first have a clear view of what is used where and how the
> changes affect end user scripts and extensions. It sounds like an
> impossible task (except for 6.0).
>
> I suggest you to take a look at the ext/filter code and what we accept.
> I spend a far amount of times to ask and listen to users to see what
> they expext. I'm quite happy with the current state and for what I
> hear, the users too.
>
> You can check the FILTER_VALIDATE_* mode, they do the same operations
> that we are discussing here. The sanitize mode only checks for
> unexpected chars.
>
>
>> So a few PHP functions properly
>> accept hex strings, but most will convert one to 0. Should anything
>> be done about this difference? I have an idea about allowing hex
>> strings in to_[long|double] using the new is_numeric... functions I
>> will propose.
>
>> Few things about the current is_numeric... and hex strings, which I
>> think I'll change in my proposal unless I hear opinions otherwise:
>> *) Leading whitespace isn't allowed
>
> They should be allowed (leading/ending).
>
>> *) A sign (±) isn't allowed
>
> It is allowed except for in the hexadecimal notation (see the manual
> page of is_numeric), so if you talk only about is_numeric and the hex
> notation, it is a bug fix.
>
>> *) Hex doubles don't work. I think they should (for *whole* numbers
>> only obviously, no "."). So '0xFFFFFFFFFF' + 0 for example, works on
>> a 32-bit system.
>
> They should not, an hexadecimal notation represents an integer (long),
> not a double. A double could be the result of a cast when it is out of
> the integer range.
>
>> If that last one can be changed, it also should be in the language
>> parser of course (you know, for $n = 0xFFFFFFFFFF;).
>
> It is the endless problem about 32/64bits issues, also I don't think
> you are considering to use double in a for loop? :)
>
>
>>> Since I've been looking at is_numeric_[string|unicode], I found a
>>> weird thing it causes; probably doesn't make sense to users; bug?
>>> Look:
>
>
>>> abs(-1e500) // float(INF)
>>> abs('-1e500') // int(1) WRONG
>
> Agreed, it should float(INF)
>
>>> abs('-1e100') // float(1.0E+100)
>>> is_finite(1e500) // bool(false)
>
>>> is_finite('1e500') // bool(true) WRONG
>
> Agreed, should float(INF)
>
>>> is_finite('1e100') // bool(true)
>>> is_numeric(1e500) // bool(true)
>>> is_numeric('1e500') // bool(false) WRONG
>
> Agreed, float(INF) as before
>
>>> is_numeric('1e100') // bool(true)
>>> 1e500 + 123 // float(INF)
>>> '1e500' + 123 // int(124) WRONG
>
> I get the feeling that the E notation has one bug, solving it should
> most of these issues. ext/filter pass all these tests successfully. But
> it had the same problems in its early days.
>
>>> You get the idea. That's because is_numeric_string() *ignores* the
>>> value from zend_strtod() if errno==ERANGE. I don't think that's
>>> right, and it doesn't happen when convert_to_double() uses
>>> zend_strtod():
>
> I have to check the sources :)
>
>
>>> Just wondering if others think is_numeric_string() should be
>>> changed in that respect? I was going to rewrite the function to
>>> improve/optimize it (and submit it of course), so I can easily
>>> change its behavior while I'm at it...
>
> It would be nice to bring consistency between functions. But changing
> the behaviors at this level can have a very large impact. It has to be
> done really carefully and will _many_ tests. I can help if you like,
> both for the tests and the implementation.
>
>>> Also, is this the desired behavior of array_count_values() (manual
>>> doesn't say; it also uses is_numeric...)?
>>>
>>> print_r(array_count_values(array(1, ' 1', ' 1 ')))
>>> Array
>>> (
>>> [1] => 2
>>> [ 1 ] => 1
>>> )
>
> This is typically an example of why we cannot not change the behaviors
> in php5, but I definitively like to do it for php 6.x.
>
> Cheers,
> -- Pierre
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
