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
>>>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
