Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70080 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 13823 invoked from network); 10 Nov 2013 10:06:19 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Nov 2013 10:06:19 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.83 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.83 smtp83.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.83] ([108.166.43.83:41371] helo=smtp83.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 39/50-12065-89A5F725 for ; Sun, 10 Nov 2013 05:06:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 505885009E; Sun, 10 Nov 2013 05:06:14 -0500 (EST) X-Virus-Scanned: OK Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id F0A665008E; Sun, 10 Nov 2013 05:06:13 -0500 (EST) Message-ID: <527F5A95.1030601@sugarcrm.com> Date: Sun, 10 Nov 2013 02:06:13 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Yasuo Ohgaki CC: "internals@lists.php.net" References: <527DF228.1080108@sugarcrm.com> <527F3B9B.8040006@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Comparison and conversion inconsistency - need more info From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Our manual does not have NULL/BOOL type behavior explanations. It does. I already sent the link, here it is again: http://www.php.net/manual/en/language.operators.comparison.php > The bug report might be confusing, but it's is not complaining -1 != > false or like, but it's complaining min() is not following standard PHP > comparison rules. This is incorrect, it does. > ----------------------------------- > if (-1 < NULL) > echo 'NULL is smaller'; > else > echo '-1 is smaller'; > ----------------------------------- > returns '-1 is smaller' as all of us expects. Surely, but since in your script the branches are switched, NULL is actually smaller. Your script just prints "-1 is smaller" when NULL is smaller. Exactly as described in the manual. > NULL is evaluated as 0 in scalar contexts, but not with min(). NULL wins I'm not sure what "scalar contexts" are, but NULL is converted to 0 as integer, however comparisons do not always do integer conversions. Please see the manual again. > negative values because of the compare_function() in zend_operators.c. > compare_function() treats NULL/BOOL type special way. (i.e Not like > expression in 'if' statement or like) This is not correct, all these operations treat NULL in the same way. You are welcome to show an example where it is treated differently, but I think it's be rather hard as they all use the same compare_function. > I think feasible solution for min() misbehavior is to use new function > that uses standard PHP comparison rule. I'll check PHP functions that min() already uses standard PHP comparison rules, by calling compare_function. > uses compare_function() later. There may be other array functions use > it. I'm not sure if there are 'internal' functions that does not perform > comparison(or conversion) non standard way like compare_function(). compare_function *is* the standard way. That's what comparison operators use, just look at the code. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227