Hi Ilia,
I take it there aren't any issues in array.c or wddx.c?
Anyway, I wanted to point out one more is_numeric_* functionality change
that I skipped in my original message, but I think it's probably a logic bug
in the old code. The end of the old function is:
if (end_ptr_double>end_ptr_long && dval) {
*dval = local_dval;
return IS_DOUBLE;
} else if (end_ptr_long && lval) {
*lval = local_lval;
return IS_LONG;
}
return 0;
It's only reached if a partial numeric match (non-zero allow_errors) is
allowed. I've not tested it, but as far as I can tell, that means if an
is_numeric_* call wanted to know about a partial match and didn't have a
pointer for the corresponding type, 0 would incorrectly be returned (or
possibly IS_LONG in case of a double). I don't know if this is much of a
real issue...
>From checking http://lxr.php.net, the first difference (returning 0) exists
in pecl/http/http_functions.c and http_request_api.c.
And either difference exists in ext/curl/streams.c. Again, not tested, but
it looks like the string '1.23foo' (double) would be treated as a long and
incorrectly fill "mr" with 1, but the string '1.23' (full match) would not.
Hope that's correct. I believe the old code was wrong, and it's correct to
treat full and partial matches the same, which my new version does.
Matt
----- Original Message -----
From: "Ilia Alshanetsky"
Sent: Tuesday, December 12, 2006
> Matt,
>
> Take a look at array.c and wddx.c
>
> On 12-Dec-06, at 11:14 AM, Matt Wilmas wrote:
>
> > ----- Original Message -----
> > From: "Ilia Alshanetsky"
> > Sent: Tuesday, December 12, 2006
> >
> >> As far as I can tell all tests still pass with the patch, although we
> >> have a number of is_numeric_string() uses that will need to be
> >> adjusted to accommodate the change to the function.
> >
> > Really, like what? I didn't see anything that stuck out...
> >
> >> Ilia Alshanetsky
> >
> > Matt
>
> Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
