Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:75156
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.79 as permitted sender)
Message-ID: <BLU436-SMTP11201A80912941972BEAE34E2040@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_E40A96A7-7445-4409-AF6D-0FE7914805A3"
MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
In-Reply-To: <CA+9eiLs2N_=FyKtUDmC8R0+aJXA5jmgMOfU5LMyNWCT2VBre+g@mail.gmail.com>
Date: Mon, 30 Jun 2014 23:29:07 +0200
CC: PHP Internals <internals@lists.php.net>
References: <CA+9eiLtCyuMVN-CN_hnLCCij4nymUiKEa26K_S_qM1PN-g-4HA@mail.gmail.com> <BLU436-SMTP6419BD328DD63EB79F19C4E2040@phx.gbl> <CA+9eiLs2N_=FyKtUDmC8R0+aJXA5jmgMOfU5LMyNWCT2VBre+g@mail.gmail.com>
To: Dmitry Stogov <dmitry@zend.com>
Subject: Re: [PHP-DEV] Wired constant expression syntax and bug
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_E40A96A7-7445-4409-AF6D-0FE7914805A3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="us-ascii"

I'll add some tests later (Please remind me if I didn't add them until =
tomorrow evening).

Bob

Am 30.6.2014 um 21:32 schrieb Dmitry Stogov <dmitry@zend.com>:
> OK. I'll commit the patch.
>=20
> According to the wired syntax, note that your example code will make =
PHP at first construct an array and then destroy it.
>=20
> why not to write $var =3D DO ? "value1" : "value2";=20
>=20
> it must be more clear and efficient.
>=20
> In case you like to keep this new syntax in PHP-5.6 at least please =
cover it with tests.
> I'm not a big fun of it, but won't object if it can't make real harm.
>=20
> Thanks. Dmitry.
>=20
>=20
> On Mon, Jun 30, 2014 at 11:21 PM, Bob Weinand <bobwei9@hotmail.com> =
wrote:
> That syntax wasn't part of the RFC because it wasn't yet possible =
(existence of IS_CONSTANT_ARRAY at that time).
> Also the use case for that one is mainly:
>=20
> class Foo {
>         public $var =3D ["value1", "value2"][DO];
> }
>=20
> And then just write
> const DO =3D 0; (or 1)
>=20
> I don't exactly know at which point that conflicts with opcache. Or if =
that really fixes the bug.
> The copying itself in your patch looks fine, but please take the =
responsibility for it and apply it yourself.
>=20
> Thanks,
> Bob
>=20
> Am 30.6.2014 um 21:06 schrieb Dmitry Stogov <dmitry@zend.com>:
> > Hi Bob,
> >
> > I'm wondered why you introduced this wired syntax in PHP-5.6.
> >
> > class FooBar {
> >               const bar =3D ["bar" =3D> 3]["bar"];
> > }
> >
> > It wasn't a part of RFC, it wasn't covered by tests, and it actually
> > doesn't make a lot of sense. May be it's better to remove it?
> >
> > Also I found a constant expression related bug, that leads to =
unpredictable
> > crashes from time to time. Previously we had IS_CONSTANT_ARRAY that =
was
> > handled in a special way. When you replaced it with IS_ARRAY, you =
missed
> > this handling, and I missed it as well when reviewed your patch. Now
> > IS_ARRAY constants might be incompletely copied from OPCache shared =
memory
> > and modified (incremented/decremented reference counter) directly in =
SHM.
> > Such modifications occur in simultaneously running processes and =
this
> > finally leads to crash on some race condition.
> >
> > It's possible to emulate the problem running the following script =
with
> > opcache.protect_memory=3D1
> >
> > <?php
> > function foo($query =3D NULL, array $exclude =3D array('q')) {}
> > foo();
> > ?>
> >
> > I propose a simple fix: =
https://gist.github.com/dstogov/b73884e252b376957ebc
> > Please review and apply if agree.
> >
> > Thanks. Dmitry.

--Apple-Mail=_E40A96A7-7445-4409-AF6D-0FE7914805A3--