Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:39467
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain realplain.com from 209.235.152.149 cause and error)
Message-ID: <013e01c8f257$1e1bbcf0$0201a8c0@pc1>
To: <internals@lists.php.net>, "Dmitry Stogov" <dmitry@zend.com>
Cc: "Nuno Lopes" <nlopess@php.net>
Date: Wed, 30 Jul 2008 10:15:33 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [PATCH] Constant expr folding (again), and other things
From: php_lists@realplain.com ("Matt Wilmas")

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