Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86570
Return-Path: <dmitry@zend.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 60220 invoked from network); 10 Jun 2015 18:02:15 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 10 Jun 2015 18:02:15 -0000
Authentication-Results: pb1.pair.com header.from=dmitry@zend.com; sender-id=pass
Authentication-Results: pb1.pair.com smtp.mail=dmitry@zend.com; spf=pass; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.216.41 as permitted sender)
X-PHP-List-Original-Sender: dmitry@zend.com
X-Host-Fingerprint: 209.85.216.41 mail-vn0-f41.google.com  
Received: from [209.85.216.41] ([209.85.216.41:35660] helo=mail-vn0-f41.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id AB/91-51179-6AB78755 for <internals@lists.php.net>; Wed, 10 Jun 2015 14:02:15 -0400
Received: by vnbf129 with SMTP id f129so9460772vnb.2
        for <internals@lists.php.net>; Wed, 10 Jun 2015 11:02:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:mime-version:in-reply-to:references:date
         :message-id:subject:from:to:cc:content-type;
        bh=fsxGyddJN3fIUK+rByM6zN5cBzMCC+wG1p+ry0e4qTE=;
        b=OVtyA3KqL6sbHdlG9zfeqkll6k510v2ONx0qxzCtabm6ii4mJSAGojmnYd4zcWnUBS
         geWw5wjAu1v/inDOFXFk3zJsL6k/76SaMcr5HH9d3gEs3O/YXzU92uzZyaEcd2u0bFCZ
         RIwb56lGXCtt+M9TKAPJmVPgusaMHi9lHi6PEkI8eprARnZR6b5qYHrqJM832zESyHxh
         yUrLoBRic8VTaUcsdA8cmbPbniYXgZzKbK5Sgj8En18Z1vm31yu8n2caPdUzOoh1mjcb
         IvlbfhT5f71yTaIqo7fgkipm/gt7gTjMO0NGEN3MIW2hcCZUuTFIMbQk73DaAj57U8MD
         ru0w==
X-Gm-Message-State: ALoCoQnP/Tyt6jr+ahCVV59l2UgDbus5ydCuUt2Nxjk4FWXFy/YxGfjuTyWxvpoTrqi+eaKpWo8iivfMWvD4qIbCDdZPndJhpAgzmem4BQV3AxT1mT+zl1GL5U7QZxVXES8UsGA8Hvh37et4jof7TXS8B4jSZm2Y+SFBx1k5IhZURo7FSZ1xFUw=
MIME-Version: 1.0
X-Received: by 10.52.228.42 with SMTP id sf10mr8587723vdc.12.1433959332466;
 Wed, 10 Jun 2015 11:02:12 -0700 (PDT)
Received: by 10.31.10.201 with HTTP; Wed, 10 Jun 2015 11:02:12 -0700 (PDT)
In-Reply-To: <CAESVnVpgOHjA0-nQ1YyyHH2JUiFut74bwpbt6S3Bh2BvyE=rCw@mail.gmail.com>
References: <CAESVnVr6oyAOCjWRWp7MGio_JNuUryPm=HKeY=fDgKRBcMXJ=Q@mail.gmail.com>
	<55513AA4.7010706@gmail.com>
	<579127CDC1B54040BEEFD4564A6F78B7@pc1>
	<CAESVnVpDXmLB-Gd_9HTyrdcnuS8g27Gezwgodb1CVLCVo0u2tg@mail.gmail.com>
	<1FAF88D0E2DE433FA299B4FAF7120880@pc1>
	<CAESVnVpBKS_0FMr-hXMWUsXURb=NbrfYXGLGVnnPH6y+byR24g@mail.gmail.com>
	<CAESVnVpkrthvKq1GCYPNH-4ujPRH-RUSqEMyVhY3X-O-kUN24g@mail.gmail.com>
	<CAESVnVpgOHjA0-nQ1YyyHH2JUiFut74bwpbt6S3Bh2BvyE=rCw@mail.gmail.com>
Date: Wed, 10 Jun 2015 21:02:12 +0300
Message-ID: <CA+9eiLsY08k3HAifptmyDCyeWBPCEt6pCYSdWrRjPHLkUK1WbA@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: Matt Wilmas <php_lists@realplain.com>, Dmitry Stogov <dmitry@php.net>, 
	Stanislav Malyshev <smalyshev@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01184d7aa26b3505182dac3f
Subject: Re: [PHP-DEV] Undefined variables undefined order
From: dmitry@zend.com (Dmitry Stogov)

--089e01184d7aa26b3505182dac3f
Content-Type: text/plain; charset=UTF-8

On Wed, Jun 10, 2015 at 6:00 PM, Sara Golemon <pollita@php.net> wrote:

> On Wed, Jun 10, 2015 at 7:50 AM, Sara Golemon <pollita@php.net> wrote:
> > On Wed, Jun 10, 2015 at 7:42 AM, Sara Golemon <pollita@php.net> wrote:
> >> Dmitry, what's the reasoning behind this diff in the first place?
> >> Doesn't the compiler fold (<const-string> . <const-string>) already
> >> anyhow?  How would we wind up with CONCAT_CONST_CONST at runtime?
> >>
> > Derp.  Looked again, and it's (const *OR* string) && (const *OR*
> > string).  I read those as ANDs initially.
> >
> > But now I'm confused again, because that makes it look like we can
> > reach this with an expression like "1 . 2" 1 and 2 are consts, but not
> > strings, so then we get to:
> >
> >   zend_string *op1_str = Z_STR_P(op1);
> >
> > Which will lead to op1_str pointing at 0x00000001 and a segfault.
> >
> > What am I missing here?
> >
> Okay, answered my own question (I need to be gentler with the [Send]
> button).
>
> Zend/zend_compile.c sets up an assumption:
>
> if (left_node.op_type == IS_CONST) {
>   convert_to_string(&left_node.u.constant);
> }
> if (right_node.op_type == IS_CONST) {
>   convert_to_string(&right_node.u.constant);
> }
>
> So any const nodes passed to CONCAT will always be strings (having
> been preconverted), and the if check using an OR make sense, because
> if it's CONST, then we KNOW it's a string, and there's no point
> testing for it.  We won't ever reach CONCAT_CONST_CONST (since that
> would be folded in the compiler), but we might reach CONCAT_CONST_CV
> or CONCAT_TMPVAR_CONST or some other combination thereof for which
> this case is set to handle.
>

exectly.
anyway CONCAT_CONST_CONST may be removed at all, at least to reduce the
code size.

TL;DR - Never mind me.  I just didn't think it all the way through.
>
> -Sara
>
> P.S. - An assert(Z_TYPE_P(op1) == IS_STRING); and assert(Z_TYPE_P(op2)
> == IS_STRING);  does seem reasonable though...  Maybe even with a
> comment referencing that we can make that assumption because the
> compiler fixes up the types.
>

ZEND_ASSERT() would be better.

Thanks. Dmitry.

--089e01184d7aa26b3505182dac3f--