ID: 22237
Comment by: rep at devdomain dot com
Reported By: peter at globalvision dot com dot au
Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: All
PHP Version: 5CVS-2003-02-15 (dev)
New Comment:
Not closed! Using September's 28 PHP5 CVS:
PHP Fatal error: Method name must be a string in
/www/var/template/%%-16/%%-1606537564/Contact.en.tpl.php
And the php file goes like this:
<?php echo $this->_plugins['function']['mailto'][0](array('address' =>
"[EMAIL PROTECTED]",'encode' => 'javascript'), $this) ; ?>
(Smarty template.)
With this postfilter it works fine:
function dev_smarty_php5b1_fix_postfilter ($sTpl, &$oSmarty) {
return preg_replace (
'/echo (\$this-\>_plugins\[\'\w+\'\]\[\'\w+\'\]\[\d+\])/',
'$dev_php5b1_fix = "{\1}"; echo $dev_php5b1_fix', $sTpl);
}
Previous Comments:
------------------------------------------------------------------------
[2003-04-19 20:06:16] peter at globalvision dot com dot au
Yup.. confirmed that the latest CVS no longer crashes...
------------------------------------------------------------------------
[2003-04-18 18:14:16] thekid at thekid dot de
No crash here.
In line 1, I assume you're expecting "hi" as an output. This will of
course not work as $bar is not set.
Modify line 1 to read:
echo $this->{$this->bar}
and you will have your expected output. Note that with
error_reporting(E_ALL) you would notice such kinds of mistakes. Also,
var_dump() helps a lot, you can actually see type information instead
of just nothing appearing:)
[EMAIL PROTECTED]:~ > cat | php5
<?php
class myClass
{
var $foo = "hi";
var $bar = "foo";
function test()
{
var_dump($this->{$this->bar});
var_dump($this->foo);
}
}
$c= new myClass();
$c->test();
?>
string(2) "hi"
string(2) "hi"
------------------------------------------------------------------------
[2003-03-23 06:46:27] peter at globalvision dot com dot au
Well... I have not had the time to solve it, but I now know pretty well
why it is caused.
**can someone please have a crack at fixing this**?
In zend_language_parser.y, the rule for object_property is either an
object_dim_list (which can be a T_STRING) or it is a
"variable_without_ibjects".
object_dim_list works for $this->foo, but $this->$foo is matched by
variable_without_objects.
HOWEVER, variable_without_objects is the match for vanilla variables,
so it consumes one '$' before it dereferences.
in other words, $this->$foo sends the $foo part off to the standard
variable compiler area which does not recognise that $foo is a
reference.
I experimented by placing a couple of rules in the lex scanner as
follows:
<ST_LOOKING_FOR_PROPERTY>"$" {
fprintf(stderr,"xxx");
yy_push_state(ST_TEST)
return '$';
}
and
<ST_TEST>";" {
fprintf(stderr,"yyy");
yy_pop_state(TSRMLS_C);
return ';';
}
<ST_TEST>{LABEL} {
fprintf(stderr,"zzz");
zendlval->value.str.val = (char *)estrndup(yytext,yyleng);
zendlval->value.str.len = yyleng;
zendlval->type = IS_STRING;
return T_VARIABLE;
}
and suddenly, it all seems to parse, however I'm clearly missing
something - it still does not display the forrect output for
echo $this->$foo;
What am I doing wrong?
------------------------------------------------------------------------
[2003-02-22 17:08:49] peter at globalvision dot com dot au
I'm assuming all OSes b/c my original report was MS Windows but a
subsequent dup report was for Linux.
I've narrowed it down a bit by running with debug mode on the ZE2
I'm 99% sure it is due to the way zend treats "$this" as special. I
don't think it's putting all the required data on the stack.
Specifically, when it processes the base_variable_without_objects bison
rule after reading T_OBJECT_OPERATOR (ie -> ) it sets yyval.u.EA.type
(see case 363 in zend_language_parser.c) but yyval.u is zero at that
time when the LH operand is $this.
Not sure why yet...
EG the following modification causes no crash:
<?php
class myClass
{
var $foo = "hi";
var $bar = "foo";
function test()
{
$t = &$this;
echo $t->$bar;
//echo $this->foo;
}
}
?>
------------------------------------------------------------------------
[2003-02-19 06:26:45] root at kitten dot net
This is pretty serious... it prevents pear from working. Can someone
please take a look at it?
Thanks
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/22237
--
Edit this bug report at http://bugs.php.net/?id=22237&edit=1
