Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:56599 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 82202 invoked from network); 24 Nov 2011 22:04:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Nov 2011 22:04:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=larry@garfieldtech.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=larry@garfieldtech.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.26 cause and error) X-PHP-List-Original-Sender: larry@garfieldtech.com X-Host-Fingerprint: 66.111.4.26 out2.smtp.messagingengine.com Received: from [66.111.4.26] ([66.111.4.26:43138] helo=out2.smtp.messagingengine.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 58/E9-26290-F4FBECE4 for ; Thu, 24 Nov 2011 17:03:59 -0500 Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id C4C6620AC1 for ; Thu, 24 Nov 2011 17:03:56 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 24 Nov 2011 17:03:56 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=3OdneKxQWEMlNPJI7k9R6L k9Kzc=; b=SJnFY6pzmEtBI2KFYYgS64dulLLLmWPGVqHuHvdEMu1u0jkctwbWW5 r+fxkkzswUK5nAuKvflNjO2miGJghq0UvkoH0tgBIny+lpE7lDE+C3Ux+oWNdSGv x2PXOtqVC0esHe/mgSngB5ofaEy0EWKmHeQLfkhTI5yJ0kIMRSPi0= X-Sasl-enc: gaRAfCA63QA3lwKONY1Vsh0kOjh/sBhc6/VXTr2xknX/ 1322172236 Received: from [192.168.42.6] (c-24-13-85-162.hsd1.il.comcast.net [24.13.85.162]) by mail.messagingengine.com (Postfix) with ESMTPSA id 824798E011E for ; Thu, 24 Nov 2011 17:03:56 -0500 (EST) Message-ID: <4ECEBF46.3090206@garfieldtech.com> Date: Thu, 24 Nov 2011 16:03:50 -0600 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: internals@lists.php.net References: <20111123015008.GA12933@panix.com> <20111123023108.GA172@panix.com> <4ECCB549.904@lsces.co.uk> <4ECCBC56.3050602@sugarcrm.com> <20111123141408.GA11940@panix.com> <20111123153100.GB13420@panix.com> <4ECD37D9.8090604@lsces.co.uk> <4ECEA547.9070605@garfieldtech.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values From: larry@garfieldtech.com (Larry Garfield) On 11/24/2011 02:58 PM, Ferenc Kovacs wrote: > On Thu, Nov 24, 2011 at 9:12 PM, Larry Garfieldwrote: > >> On 11/23/2011 12:13 PM, Lester Caine wrote: >> >>> Richard Quadling wrote: >>> >>>> I agree with Daniel on this. >>>> >>>> Just looking for any test relating to isset() to see what tests will >>>> now fail. >>>> >>> >>> So it's not just me :) >>> I am seeing this break real world projects and can't see a easy way to >>> fix the break. There is nothing really wrong with the current code >>> except that the sub keys have yet to be populated. >>> >> >> This is going to be a huge problem for Drupal. Drupal uses deep >> associative array structures a lot, by design. That means we isset() or >> empty() on arrays a lot. I haven't had a chance to test it yet, but I see >> this change breaking, um, A LOT. And as Daniel noted, the fix is to turn >> one line of very readable code into 8 lines of hard to read code. >> > > Did you managed to read the whole thread? > I'm asking because there were lot of confusion about the actual impact of > this problem, and Lester particularly seemed confused. To be fair, no, I hadn't read the whole thread by the time I sent that. (One of the challenges of long fast-moving threads is they're hard to keep up with.) > "There is nothing really wrong with the current code except that the sub > keys have yet to be populated." > that isn't true, if the array or some sub elements are empty("yet to be > populated"), you won't bump into this change. See my previous mail for the > exact details. > > so the above mentioned one liner: > > "if (isset($arr['package']['attribs']['version'])) {" > > what could go wrong: > $arr is not an array, but a string -> it would fatal on 5.3(Fatal: cannot > use string offset as an array), but it would work with 5.4 > $arr['package'] is not an array but a string -> false on 5.3, true on 5.4 > (this is the worst case) > $arr['package']['attribs'] is not an array but a string -> true on both 5.3 > and 5.4 (so you are already screwed) So to clarify, what Drupal does on a regular basis is something like: if (isset($foo['bar']['baz']['beep'])) { // Assume that bar, baz, and beep all exist, and that beep has a value } // or sometimes if (!empty($foo['bar']['baz']['beep'])) { // Assume that bar, baz, and beep all exist, // and that beep has a meaningful value } Generally $foo, bar, and baz will all be arrays, and if they're not it means someone else had a bug somewhere. Of course, Drupal module developers never have bugs in their code that accidentally puts a string where they should have put an array, no, not at all. :-) (Generally when that happens we already hit a "first argument to foreach() must be an array" error.) Currently we don't use ArrayAccess anywhere aside from inheriting it from PDO. If that doesn't change, then I rescind my previous panic attack. --Larry Garfield