Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:86555
Return-Path: <php@golemon.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 31297 invoked from network); 10 Jun 2015 15:00:34 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 10 Jun 2015 15:00:34 -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.217.182 as permitted sender)
X-PHP-List-Original-Sender: php@golemon.com
X-Host-Fingerprint: 209.85.217.182 mail-lb0-f182.google.com  
Received: from [209.85.217.182] ([209.85.217.182:32866] helo=mail-lb0-f182.google.com)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id E0/E2-15306-11158755 for <internals@lists.php.net>; Wed, 10 Jun 2015 11:00:34 -0400
Received: by lbcue7 with SMTP id ue7so30556518lbc.0
        for <internals@lists.php.net>; Wed, 10 Jun 2015 08:00:29 -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:sender:in-reply-to:references:date
         :message-id:subject:from:to:cc:content-type;
        bh=FEbyhaeVgE7Wp3c9LPrerTW7/ecVP+WkA2bx0z8gsko=;
        b=g5NsOK9XT5ziI6jL0KLLEykZfvelK0Ju82/2zphiADEndbABW736W9W7CFHMyalUq4
         7eubUz4N3eHWmtqB3v0lX5TVdJfB37xDrYGAzwdi+brm/dnpbFO0IcVX+yLWdH6CyGCj
         9ydIhTI02IKGYfJo0OaqGkAFptlk5HCANywPa8/SRGrntBL0m/l8kjuyIuqSxCuCxwCQ
         MbAc774Myg2ZnFdfRXozHLQ0A7NyhsaJeu6N17pJsGf7EOuYeCnZjKCo+ReR+PWHixDS
         2u9I+kuQDCwr80OLqKGEDdqJNXi586kdTrGKy/QhzTXl+rDnUGtaXcGnquMDZ9QXw+rK
         rzzQ==
X-Gm-Message-State: ALoCoQlIEcf9J/P1HeSBYl3kE0adOpF5lcJlYdOJZQb0rpZcDeGxWG21/BA1DcVqam9B10eJBbfk
MIME-Version: 1.0
X-Received: by 10.152.37.196 with SMTP id a4mr4564832lak.59.1433948429075;
 Wed, 10 Jun 2015 08:00:29 -0700 (PDT)
Sender: php@golemon.com
Received: by 10.112.11.134 with HTTP; Wed, 10 Jun 2015 08:00:28 -0700 (PDT)
X-Originating-IP: [199.201.64.2]
In-Reply-To: <CAESVnVpkrthvKq1GCYPNH-4ujPRH-RUSqEMyVhY3X-O-kUN24g@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>
Date: Wed, 10 Jun 2015 08:00:28 -0700
X-Google-Sender-Auth: 649plx3-8N4q223QDcY3p4Twerg
Message-ID: <CAESVnVpgOHjA0-nQ1YyyHH2JUiFut74bwpbt6S3Bh2BvyE=rCw@mail.gmail.com>
To: Matt Wilmas <php_lists@realplain.com>
Cc: Dmitry Stogov <dmitry@php.net>, Stanislav Malyshev <smalyshev@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Undefined variables undefined order
From: pollita@php.net (Sara Golemon)

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.

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.