Re: is_numeric_string causes function inconsistency

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