Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65640
Return-Path: <brian@moonspot.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 42145 invoked from network); 4 Feb 2013 17:28:06 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 4 Feb 2013 17:28:06 -0000
Authentication-Results: pb1.pair.com header.from=brian@moonspot.net; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=brian@moonspot.net; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain moonspot.net designates 72.5.90.26 as permitted sender)
X-PHP-List-Original-Sender: brian@moonspot.net
X-Host-Fingerprint: 72.5.90.26 mail.dealnews.com Linux 2.6
Received: from [72.5.90.26] ([72.5.90.26:35772] helo=mail.dealnews.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 97/80-38697-5AFEF015 for <internals@lists.php.net>; Mon, 04 Feb 2013 12:28:06 -0500
Received: from localhost (localhost [127.0.0.1])
	by mail.dealnews.com (Postfix) with ESMTP id A8CE6617D21A;
	Mon,  4 Feb 2013 12:28:02 -0500 (EST)
X-Virus-Scanned: amavisd-new at dealnews.com
Received: from mail.dealnews.com ([127.0.0.1])
	by localhost (atl-zimbra1.dealnews.com [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id rm+yp885XfKs; Mon,  4 Feb 2013 12:28:01 -0500 (EST)
Received: from Brians-MacBook-Pro.local (h105.248.18.98.static.ip.windstream.net [98.18.248.105])
	by mail.dealnews.com (Postfix) with ESMTPSA id F20B4617D217;
	Mon,  4 Feb 2013 12:28:00 -0500 (EST)
Message-ID: <510FEFA0.9060400@moonspot.net>
Date: Mon, 04 Feb 2013 11:28:00 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Frank Liepert <Frank.Liepert@gmx.de>
CC: 'Gustavo Lopes' <glopes@nebm.ist.utl.pt>, 
 'Patrick Schaaf' <php@bof.de>,
 internals@lists.php.net, 'Derick Rethans' <derick@php.net>, 
 'Martin Jansen' <martin@divbyzero.net>
References: <510EA95F.40503@divbyzero.net> <alpine.DEB.2.02.1302031737430.5054@whisky.home.derickrethans.nl> <2835262.zO39iNXCyM@rofl> <002d01ce02c8$dbb6d430$93247c90$@Liepert@gmx.de> <op.wrzbosnpidpuyk@damnation.nl.lo.geleia.net> <003401ce02db$53073e00$f915ba00$@Liepert@gmx.de>
In-Reply-To: <003401ce02db$53073e00$f915ba00$@Liepert@gmx.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: AW: AW: [PHP-DEV] FILTER_VALIDATE_INT and +0/-0
From: brian@moonspot.net (Brian Moon)

> Both statements are wrong, since the purpose of the filter extension
> is to validate strings. I found this information in BR #52884 (see
> last comment). Maybe it should be added to the docs? It's nonsense to
> say, that FILTER_VALIDATE_INT must work like var_dump() since they
> are both serving different purposes.
>
> With this information I agree on your opinion.
>
> var_dump(filter_var('-0',FILTER_VALIDATE_INT)); // int(0) instead of
> the prior bool(false) var_dump('-0'); // string(2) "-0"
> var_dump(is_int('-0')); // bool(false)

var_dump does not attempt to convert a string into an integer when 
possible. FILTER_VALIDATE_INT does. This is much more analagous to 
FILTER_VALIDATE_INT IMO.

$ php -r "echo (is_numeric('-0')) ? (int)'-0' : null;"
0

I am not intimately familiar with the internals of filter, but I 
replaced code in userland like this with filter calls.

Brian Moon