Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25331
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <1133.209.254.223.2.1155409859.squirrel@www.l-i-e.com>
In-Reply-To: <002901c6bde3$f3805ea0$0201a8c0@pc1>
References: <005101c6b930$83f30b30$0201a8c0@pc1>   
    <00fa01c6bd37$d61d1940$0201a8c0@pc1>
    <5580.67.108.68.40.1155322579.squirrel@www.l-i-e.com>
    <002901c6bde3$f3805ea0$0201a8c0@pc1>
Date: Sat, 12 Aug 2006 14:10:59 -0500 (CDT)
To: "Matt W" <php_lists@realplain.com>
Cc: internals@lists.php.net
Reply-To: ceo@l-i-e.com
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] is_numeric_string causes function inconsistency
From: ceo@l-i-e.com ("Richard Lynch")

[Apologies for having accidentally responded to Matt W off-list, and
now bringing it back on-list without asking...]

On Sat, August 12, 2006 2:50 am, Matt W wrote:
> From: "Richard Lynch"
> Sent: Friday, August 11, 2006
>
>
>> Leading whitespace in PHP means that it's not a number, it's a
>> string,
>> and it turns into 0.
>>
>> If you change that, it will break a lot of stuff.
>>
>> Don't.
>>
>> :-)
>
> This is basically what Jochem Mass said, and my reply was:
>
> "Leading whitespace is already allowed with PHP's is_numeric()
> function (and
> corresponding internal one), math operations, etc.  Only when it
> precedes
> .123 or -.123 does the behavior change. :-)"
>
> So with math operations, leading whitespace doesn't cause it (an
> otherwise
> numeric-prefix string) to turn into 0 (and never has), unless the
> first
> character(s) after the whitespace are "." or "-."  Changing this
> specific
> (and rarely, if ever, occuring) scenario shouldn't break stuff... but
> merely
> make it operate the way it should. :-)

But I think you are talking about making changes to the way this works:

http://example.com/?foo=%20.123
<?php
$foo = $_GET['foo'];
if (is_numeric($foo)){
  //error out
}
$query = "something involving '$foo'";
?>

If you break that, you're in big trouble to a lot of scripts all over
the planet, which rely on the leading space to trap their SQL problem.

I never actually use is_numeric, and would expect it to follow the
same "rules" as PHP's internal type-juggling mechanism.

I believe leading spaces should NOT be allowed for type-juggling, not
is_numeric, because GET/POST/COOKIE data should be subject to the most
stringent constraints reasonable to avoid security injections.

I really think the community is best served by K.I.S.S. which means
is_numeric should follow the same "rules" as type-juggling, so that
the programmer is not confused by which does what, and that those
rules for what constitutes is_numeric() should not have leading (or
trailing) spaces.

There is also a paradigm of only specifically allowing what "should
be" valid for a validity/security check on data constraints.

While I don't think leading/trailing spaces are likely to constitute a
Security Issue, there is a Principle at work that I think should be
applied.

Surely is_numeric(trim($foo)) is the right answer for the programmer
who specifically wants to allow spaces.

The fact that PHP even allows leading spaces for this is what I would
consider a bug:
<?php
$foo = ' 123';
$bar = (int) $foo;
echo "bar: $bar";
?>

EXPECTED OUTPUT:
bar:

ACTUAL OUTPUT:
bar: 123

I understand the argument that this buggy behaviour is inconsistent
with ' .123' and ' -.123' but would counter that the bug is in
allowing the leading spaces, and is not best addressed by making it
consistently buggy.

jmho

-- 
Like Music?
http://l-i-e.com/artists.htm