Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86572
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 64513 invoked from network); 10 Jun 2015 18:32:21 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 10 Jun 2015 18:32:21 -0000
Authentication-Results: pb1.pair.com smtp.mail=dmitry@zend.com; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=dmitry@zend.com; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain zend.com designates 209.85.216.50 as permitted sender)
X-PHP-List-Original-Sender: dmitry@zend.com
X-Host-Fingerprint: 209.85.216.50 mail-vn0-f50.google.com  
Received: from [209.85.216.50] ([209.85.216.50:41895] helo=mail-vn0-f50.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 89/00-63696-3B288755 for <internals@lists.php.net>; Wed, 10 Jun 2015 14:32:20 -0400
Received: by vnbg190 with SMTP id g190so9567074vnb.8
        for <internals@lists.php.net>; Wed, 10 Jun 2015 11:32:17 -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=Aaqfpn0FySN6WVeDtHGoAWvhur3yqHtU0+6/VgzswKE=;
        b=JKVBurkH6jxxghIxCPaHFHWooGJ5f74GMjzVSJdkngCGzNYXUJGqA7vk5RRvayMcpe
         0SwcWvOoo/4cj2xVCi0zvIzXmeH/O5K/h5e5eMruBOng3vsiqNZL0oR8luivU6mv2un6
         xQxAAeYzML3xDEf2Fqv+ZvPYuKr0NBBnLYIxeF2tR42miZ3kl/N44kF3kOy4PVjj9nQm
         xvs2WWOp3Xi8e+1TQjhoPRJedCLsidM1LVLsQFCn+jFUY9I8+KzSiRTCaLw5zo1jV9TV
         gwRfGfewouxS2GlKVjb5GKfHl8bFbFOp+5t7XYrEBopreZFPp2da8q58ukSETK0GN6E1
         0Vkw==
X-Gm-Message-State: ALoCoQne3O7MDta8Jwvq0RxfBlPVeU1Dquqbi/P368Bh72uaxYBcDVCQljZaZ54HKVpckFYvY2pBnGtimFGNE/yGxTILRa1mi4DVSnSfMiwEBqBD6kRKosil6m73uVO3RTQJIdFru1R1SsHiL19LyrTfUPPhsBNZ3nxEmngIMeMW5vpJo5WyfJg=
MIME-Version: 1.0
X-Received: by 10.52.88.111 with SMTP id bf15mr8870273vdb.20.1433961137202;
 Wed, 10 Jun 2015 11:32:17 -0700 (PDT)
Received: by 10.31.10.201 with HTTP; Wed, 10 Jun 2015 11:32:16 -0700 (PDT)
In-Reply-To: <CA+9eiLsY08k3HAifptmyDCyeWBPCEt6pCYSdWrRjPHLkUK1WbA@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>
	<CA+9eiLsY08k3HAifptmyDCyeWBPCEt6pCYSdWrRjPHLkUK1WbA@mail.gmail.com>
Date: Wed, 10 Jun 2015 21:32:16 +0300
Message-ID: <CA+9eiLtiXO16nFiXzGXOX9=m8CECeG55+HL4ZiPGBJcLgD0Gvg@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=20cf307cfbe634823605182e1857
Subject: Re: [PHP-DEV] Undefined variables undefined order
From: dmitry@zend.com (Dmitry Stogov)

--20cf307cfbe634823605182e1857
Content-Type: text/plain; charset=UTF-8

Hi Sara,

https://gist.github.com/dstogov/6a90601872b538d2ddd6

I see no problems committing this (running tests now).

Thanks. Dmitry.

On Wed, Jun 10, 2015 at 9:02 PM, Dmitry Stogov <dmitry@zend.com> wrote:

>
>
> 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.
>
>

--20cf307cfbe634823605182e1857--