Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25377
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <006401c6c12e$54990a50$0201a8c0@pc1>
To: <internals@lists.php.net>, "Pierre" <pierre.php@gmail.com>
References: <005101c6b930$83f30b30$0201a8c0@pc1> <00fa01c6bd37$d61d1940$0201a8c0@pc1> <20060811141931.2ef39365@pierre-u64> <015b01c6bd4b$c6c47b00$0201a8c0@pc1> <fe05d1540608110810g78f521e7r2260686a8bfa9d01@mail.gmail.com>
Date: Wed, 16 Aug 2006 07:20:15 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] is_numeric_string causes function inconsistency
From: php_lists@realplain.com ("Matt W")

Hi Pierre,

After checking places where is_numeric... functions are used
(http://lxr.php.net/ident?i=is_numeric_string), it looks like changing to
allow *trailing* spaces would have an impact in zend_operators.c for at
least compare_function() (and I guess increment_function() too).  e.g. ('1'
== '1  ') is now FALSE.  I don't have a preference for trailing whitespace
(and that behavior *is* consistent now), though it does seem logical to
allow in PHP's is_numeric() function.  Maybe you would have a "flags"
parameter for internal is_numeric... (instead of only "allow_errors") that
says what things to allow...

More below.

----- Original Message -----
From: "Pierre"
Sent: Friday, August 11, 2006


> Hi Matt,
> ...
> +/- are not allowed for hex. I think we should make the difference
> between a string conversion and the parser.
>
> (a) $a = - 0xFF
> (b) $a = " - 0xFF; "
>
> (a) is a perfectly valid expression within a _script_ (just like
> $a=-2;), however (b) is a string and will require a _cast_ to INT. The
> two cases should not be processed the same way.
>
> (a) can be read as $a = -1; $a *= 0xFF;
> (b) is only a string assignement, it will be casted to INT when
> required and failed (int(0)).

Yes, I noticed that in the parser a negative number is 2 operations (parse
number, and negate -- actually other way around I guess :-)).  So it's
like -(123).  But with a string conversion, it's one operation, and no
whitespace would be allowed after sign for a non-hex number either: '- 123'
+ 0 is 0.  *That's* the reason I thought a sign should logically be allowed
for hex also.  The C strtol() function allows signs with hex I believe (I
know zend_u_strtol() does).  Not a big concern for me, mostly thinking of
consistency. :-)

>> Well, I think of the hex notation as just a whole number (non-floating)
of
>> whatever range/size.  About the cast, yeah, I see that's what is done now
in
>> the parser if the hex number is between LONG_MAX and ULONG_MAX -- results
in
>> a double.  hexdec(), etc. will also return a double if needed.
>>
>> Right now, since hex doubles don't work, you also have (on 32-bit):
>
> I don't understand what you mean by hex double :) Do you mean that we
> should convert out of range HEX to double in any case?

Yeah, I mean hex too large for long. :-)  In parser and is_numeric..., it
_looks like_ converting out-of-range hex to double _was desired_, but the
comments say "strtod() messes up hex", etc.  I figured that issue could be
solved in both places by doing a "manual conversion" to double in case of
too large hex numbers.

>> That reminds me, a "(number)" typecast would be nice to have. :-)
>
> number is a human thing, I'm not sure it fits our needs :)

The pseudo-type "number" is used in the manual, so I thought it might make
sense to have, meaning "whatever will hold this value: 'int' or
'double'/float'."  Of course, "+ 0" will do the same, but typecasts are a
bit more elegant. :-)

> Cheers,
> --Pierre

Matt