Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:103076 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 44241 invoked from network); 10 Aug 2018 15:13:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Aug 2018 15:13:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=php@golemon.com; spf=softfail; sender-id=softfail Authentication-Results: pb1.pair.com header.from=php@golemon.com; sender-id=softfail Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.220.176 as permitted sender) X-PHP-List-Original-Sender: php@golemon.com X-Host-Fingerprint: 209.85.220.176 mail-qk0-f176.google.com Received: from [209.85.220.176] ([209.85.220.176:46200] helo=mail-qk0-f176.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E3/F4-18754-97BAD6B5 for ; Fri, 10 Aug 2018 11:13:00 -0400 Received: by mail-qk0-f176.google.com with SMTP id 191-v6so6556142qki.13 for ; Fri, 10 Aug 2018 08:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=golemon-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=kpN9l3EYqoNK0OtcWuYVJpUOpv0jyN5oTb9d8onU/TY=; b=hXxLGg/iSTvw2J8DQvIyShL2SfFLM6eQkpwXJVuaP1FDkfAD5JAwedU4PqhCEmaHbo h8k/1IPZlLcsEB7VmCq9/Nbxck0L/FwkB9GhmOsL89wSyGkwb40ukJ2z/mTbMCuhDvhU wnzgQpmvFR643rGKNCw1/Luea5FZHXM764U4Uc25C5LAWA3WCRctLfsDGq41Tj1Y/WSV aVS4VbknwjOhDLpMcdt5UdPtovz1RVQWGA+GzBtw0IdANkZd7F5o2Ou0ZQIvCEf5/Kqt p9SXdMBsQOwvwgJ7Q7Ah/EMkuhCVDYAAEXzf06WveqyBSzyWCnyx/l12aMoF8mbIp3/3 A9Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=kpN9l3EYqoNK0OtcWuYVJpUOpv0jyN5oTb9d8onU/TY=; b=lk97dT1LcgV3ox7bfT7T/SmYyIEloTNqbVkLXz+gTasGm2Q1MxBPRQY4FIu12jjf5G lgRjs8wYMo8H8LrV+rIRgXbeVzsw/hSH5lswfrT6hnGyUB6tycKfyD+Pw8d/fE5aKD50 SCstxeM9ooFienIKGZ7rA9hsRF+F3L7RCOdXcxFyL/w14O+kR2TahqusgiJY7H0CbMN1 Zt1Jf94dru0GlLFkwluNsObqBCt19T2HvS8Fx6IxOZCagBA694BBSuL5vVxzKe/7o4ZE 3jWQCLn7RY60mhKcxLewo85LCDx6G5oNzGkRagxRLicDNRVIToMZRpMeznrXi9XZuF4u McgA== X-Gm-Message-State: AOUpUlEbQCsHHLNg8RgplbNZy5uuLYjcV6OBeCnL00JZe/nOZOQJuIfg lR9XErxfi3SysrSxct2ss1xvSVPz4noEz6JLIMjVZGeOjJU= X-Google-Smtp-Source: AA+uWPz6TexE328sxMjhR9Yz5sjo+PIByqrGQ6xsLe1qjYf/LkakcrvDsUe+W6kgvGUFkQZ4y1/u2MoVRy/XeFC88b8= X-Received: by 2002:a37:9e17:: with SMTP id h23-v6mr5885984qke.269.1533913974765; Fri, 10 Aug 2018 08:12:54 -0700 (PDT) MIME-Version: 1.0 Sender: php@golemon.com Received: by 2002:a0c:ada6:0:0:0:0:0 with HTTP; Fri, 10 Aug 2018 08:12:54 -0700 (PDT) X-Originating-IP: [98.213.160.75] Date: Fri, 10 Aug 2018 10:12:54 -0500 X-Google-Sender-Auth: yrWlB61S4JX6P80PeTGSryu0nv8 Message-ID: To: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: The curious case of the comparable objects. From: pollita@php.net (Sara Golemon) One of the contributors for the "Because, PHP" page came up with a fun example where the result of object comparison changes upon observation of that object. class A { public $a; } class B extends A { public $b; } $a = new B(); $a->a = 0; $a->b = 1; $b = new B(); $b->a = 1; $b->b = 0; var_dump($a < $b); // bool(true) print_r($a); // Output is unimportant var_dump($a < $b); // bool(false) Tracked this down to the introduction of slotted object properties introduced in PHP 5.4 and some optimistic logic contained in zend_object_handlers.c. TL;DR - The print_r is materializing the ->properties HashTable in the first object. Once that happens, zend_std_compare_objects() flips from walking the slotted properties in properties_table to materializing both ->propoperties HashTables and using a symtable compare. The result differs, because rebuild_object_properties walks ->properties_info which may not necessarily be in the same order as the values ->properties_table. See also my writeup here: https://3v4l.org/NLZNm So the questions for us are: 1. Does this matter? (I think so, it's spooky action at a distance) 2. Is it a bug introduced in 5.4 that's okay to fix? Or would fixing it count as a BC break due to how long it's been broken? (I say fixable bug, the BC break was at 5.4) 3. If yes to 1&2, how far back do we fix it? Bugfix branches (7.1+)? Or would a change like this in branch be too much? Surely at least 7.3 could be fixed. -Sara