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.
> ' .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
