Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76735
Return-Path: <php@mabe.berlin>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 40182 invoked from network); 20 Aug 2014 17:31:56 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 20 Aug 2014 17:31:56 -0000
Authentication-Results: pb1.pair.com smtp.mail=php@mabe.berlin; spf=permerror; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=php@mabe.berlin; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain mabe.berlin from 80.237.132.171 cause and error)
X-PHP-List-Original-Sender: php@mabe.berlin
X-Host-Fingerprint: 80.237.132.171 wp164.webpack.hosteurope.de  
Received: from [80.237.132.171] ([80.237.132.171:49083] helo=wp164.webpack.hosteurope.de)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id DA/12-29327-A8BD4F35 for <internals@lists.php.net>; Wed, 20 Aug 2014 13:31:56 -0400
Received: from dslb-188-102-026-115.188.102.pools.vodafone-ip.de ([188.102.26.115] helo=[192.168.178.30]); authenticated
	by wp164.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
	id 1XK9jh-0000xu-T2; Wed, 20 Aug 2014 19:31:49 +0200
Message-ID: <53F4DB7F.4010801@mabe.berlin>
Date: Wed, 20 Aug 2014 19:31:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Michael Wallner <mike@php.net>, =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?=
 <johannes@schlueters.de>, Tjerk Meesters <tjerk.meesters@gmail.com>
CC: Sara Golemon <pollita@php.net>, 
 PHP internals <internals@lists.php.net>
References: <53F1094B.4040100@mabe.berlin>	 <CAESVnVr3QJ56Ynu1cN+745fZEkq+Qas=5ecvQcF0jBX7QhdaMg@mail.gmail.com>	 <53F1F534.50109@mabe.berlin> <1408373244.2617.344.camel@guybrush>	 <37CD1B56-B84F-4586-A631-F3C7F2547FBE@gmail.com>	 <1408375856.2617.353.camel@guybrush> <1408376583.2617.357.camel@guybrush> <53F46671.8020601@mabe.berlin> <53F47C73.4090205@php.net>
In-Reply-To: <53F47C73.4090205@php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-bounce-key: webpack.hosteurope.de;php@mabe.berlin;1408555916;4b9a9943;
Subject: Re: [PHP-DEV] [RFC] Binary String Comparison
From: php@mabe.berlin (Marc Bennewitz)


On 20.08.2014 12:46, Michael Wallner wrote:
> On 20/08/14 11:12, Marc Bennewitz wrote:>
>>
>> On 18.08.2014 17:43, Johannes Schlüter wrote:
>>> On Mon, 2014-08-18 at 17:30 +0200, Johannes Schlüter wrote:
>>>>     foreach ($db->query("SELECT id, title FROM entries") as $row) {
>>>>         echo "<tr><td";
>>>>         if ($row[0] == $_GET['highlight_id']) {
>>>>             echo " background='#ff0000'";
>>>>         }
>>>>         echo ">".htmlentities($row[1])."</td></tr>";
>>>>     }
>>>>
>>>> will suddenly fail. How wonderful! (irony)
>>>
>>> Just to make this more fun: Assume $db is PDO then the behavior will
>>> depend on the driver (and for some drivers even at the configuration,
>>> i.e. setting of PDO::ATTR_EMULATE_PREPARES with MySQL) what will happen.
>>
>> I don't understand exactly what you mean here. This RFC has nothing todo
>> with DB layer and PDO.
>>
>> Do you have any example where a DB returns integers differently?
> 
> php -r '$p = new PDO("mysql:user=root"); \
>   $s=$p->prepare("SELECT 1"); $s->execute(); \
>   var_dump($s->fetchAll()); \
>   $p->setAttribute(PDO::ATTR_EMULATE_PREPARES,false); \
>   $s=$p->prepare("SELECT 1"); $s->execute(); \
>   var_dump($s->fetchAll());'
> 
> array(1) {
>   [0]=>
>   array(2) {
>     [1]=>
>     string(1) "1"
>     [2]=>
>     string(1) "1"
>   }
> }
> array(1) {
>   [0]=>
>   array(2) {
>     [1]=>
>     int(1)
>     [2]=>
>     int(1)
>   }
> }

Thank's for the explanation, but this is nothing that runs into issues
because:
- In case 1 the result number will be a string "1" that is equal with
another string of "1". Only if "1" will be compared to something like
"01", " 1", "0x1" the result will no longer be the same.
- In case 2 the DB layer already returns an integer and on comparing
this to a string the string will be converted to an integer, too -
nothing changed here by the RFC

To make the example of Johannes fail the DB layer have to return the
integer as string but not formed in a standard human way.

Marc