Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27064
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 209.142.136.132 cause and error)
Message-ID: <00a401c72269$2cabde40$0201a8c0@pc1>
To: <internals@lists.php.net>, "Ilia Alshanetsky" <ilia@prohost.org>
References: <014f01c71dfd$f0431cd0$0201a8c0@pc1> <F518403D-5926-4065-886A-E9CF8CF60914@prohost.org> <018301c71e06$9ef4f840$0201a8c0@pc1> <EA502DBE-516A-4C3F-8A55-AEFD86B0676E@prohost.org> <019301c71e08$9837bdb0$0201a8c0@pc1> <DEEBAB31-4EE4-428D-BC84-3026C018C20F@prohost.org>
Date: Sun, 17 Dec 2006 23:55:51 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [PATCH] New, optimized is_numeric_string, and other number stuff
From: php_lists@realplain.com ("Matt Wilmas")

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