Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39497
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.163 as permitted sender)
Message-ID: <4891A769.6090306@zend.com>
Date: Thu, 31 Jul 2008 15:52:09 +0400
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: Matt Wilmas <php_lists@realplain.com>
CC: internals@lists.php.net, Nuno Lopes <nlopess@php.net>
References: <013e01c8f257$1e1bbcf0$0201a8c0@pc1> <4890B18E.7000500@zend.com> <00e001c8f302$e8100fb0$0201a8c0@pc1>
In-Reply-To: <00e001c8f302$e8100fb0$0201a8c0@pc1>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PATCH] Constant expr folding (again), and other things
From: dmitry@zend.com (Dmitry Stogov)

Hi Matt,

For now I would like to disable "-CONST" constant expression which
started to work after your patch.

Later we are able to implement the complete constant expressions support.

Thanks. Dmitry.

Matt Wilmas wrote:
> Hi Dmitry,
> 
> ----- Original Message -----
> From: "Dmitry Stogov"
> Sent: Wednesday, July 30, 2008
> 
>> Hi Matt,
>>
>> does the following code work with your patch?
>>
>> <?php
>> function foo() {
>> static $a = A + B;
>> var_dump($a);
>> }
>> const A = 1;
>> const B = 2;
>> foo();
>> ?>
>>
>> It would be hard to explain why some of constant expression work, but
>> others don't.
> 
> No, it doesn't.  That would of course require additional changes (I don't
> know how to do that, didn't even look into it), and was also mentioned with
> Nuno's patch.  I just included the part I did for something "closer" to what
> was talked about last time.  The only explanation I know of would be that it
> only works with *literals*, not named constants.  But yes, it's hard to
> understand. :-)
> 
> But anyway, it doesn't really matter to me about that, the main point (like
> Nuno's) was the the folding of constant expressions in the other areas
> (especially negative numbers).  And like I said, it's more useful after
> constant substitution with function flags being ORed and things like that...
> But that could always be applied at a later date/version since it doesn't
> break compatibility, right?
> 
>> Anyway, it's too late for this patches.
>> 5.3 is going to be frozen.
> 
> Well, what about the behavior change I mentioned?  Something should be done
> about that, I'm sure.  That's what the second small patch
> ("signed_expr_tweaks") was for.
> 
> Actually, I wrote the above right after getting your message, but didn't
> send it then, because I had only been thinking about the parser, and thought
> of a more proper fix in zend_compile.c for the behavior difference (and
> something else).  I will send the fix shortly in a reply to the previous
> thread about constant substitution... :-)
> 
>> Thanks. Dmitry.
> 
> Thanks,
> Matt
> 
> 
>> Matt Wilmas wrote:
>>> Hi Dmitry, all,
>>>
>>> I was going to send this patch as a companion one to go with the
>>> compile-time constant substitution change (Nuno sent a message about
> this
>>> [1] last Sep. with a patch [2]), BUT I also realized that some
> different,
>>> inconsistent behavior is possible because of that change.
>>>
>>> First, the folding optimization part, which I don't know if you'll want
> to
>>> use (though it seems pretty simple/safe to apply at any time), does the
> same
>>> thing as Nuno's patch, but with a different implementation.  This is
> even
>>> more of an optimization when combined with constant substitution, for
> ORing
>>> function flags, etc.
>>>
>>> At the time, one of the objections (?) was that it didn't allow the same
>>> constant expressions to initialize static variables and class
>>> members/constants.  (Though I don't see much relation: hidden, internal
>>> optimization vs. actual syntax change/enhancement.)  So I also added
> support
>>> for arithmetic, bitwise, and concatenation operators (not logical or
>>> comparison) in that context.  Anyway, should be fairly simple to
>>> understand... :-)
>>>
>>> Now, the different, inconsistent behavior that's possible after the
> constant
>>> substitution change.  This code, for example:
>>>
>>> function foo() {
>>>     static $a = -PHP_INT_MAX;
>>> }
>>>
>>> Would have previously given "Unsupported operand types".  Now it can
> work
>>> because the value of PHP_INT_MAX may be substituted first.  Fine, good;
>>> except that it won't be substituted if it's in a namespace or
>>> ZEND_COMPILE_NO_CONSTANT_SUBSTITUTION is set, and then the error occurs.
>>>
>>> I thought the best solution was to disallow constants in a
> "static_scalar"
>>> expression (e.g. only literals).  This shouldn't break anything unless
>>> someone was using - or + signs on TRUE/FALSE/NULL. :-O  That will cause
> a
>>> parse error with my changes.  Also:
>>>
>>> function foo() {
>>>     static $a = -'abc'; // 0
>>>     static $b = +'abc'; // abc
>>>     $c = +'abc'; // 0
>>> }
>>>
>>> So I made the static_scalar unary + operator "do something" and behave
> like
>>> the regular one.  Again, shouldn't break anything unless someone was
>>> applying + to literal strings or arrays!
>>>
>>> Full patch with constant folding, etc.
>>> http://realplain.com/php/const_folding.diff
>>> http://realplain.com/php/const_folding_5_3.diff
>>>
>>> -OR-, basic patch only containing the fix for signed static scalars, and
>>> only an optimization to save the opcode for unary - and + applied to a
>>> constant value (e.g. negative numbers, primarily):
>>> http://realplain.com/php/signed_expr_tweaks.diff
>>> http://realplain.com/php/signed_expr_tweaks_5_3.diff
>>>
>>>
>>> Thoughts...?  Thanks,
>>> Matt
>>>
>>>
>>> [1] http://marc.info/?l=php-internals&m=118925033731019&w=2
>>> [2] http://web.ist.utl.pt/nuno.lopes/zend_constant_folding.txt
>>>
>