Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:45340 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 23260 invoked from network); 23 Aug 2009 20:48:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 23 Aug 2009 20:48:07 -0000 Authentication-Results: pb1.pair.com header.from=php@stefan-marr.de; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php@stefan-marr.de; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain stefan-marr.de from 85.88.12.247 cause and error) X-PHP-List-Original-Sender: php@stefan-marr.de X-Host-Fingerprint: 85.88.12.247 toolslave.net Received: from [85.88.12.247] ([85.88.12.247:44580] helo=uhweb12247.united-hoster.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 82/5A-03363-40BA19A4 for ; Sun, 23 Aug 2009 16:48:05 -0400 Received: from cust194-138.dsl.versadsl.be ([62.166.194.138] helo=[192.168.0.10]) by uhweb12247.united-hoster.com with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1MfJyl-0008Ne-NZ for internals@lists.php.net; Sun, 23 Aug 2009 22:47:58 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Date: Sun, 23 Aug 2009 22:47:49 +0200 Message-ID: To: internals@lists.php.net Mime-Version: 1.0 (Apple Message framework v1074) X-Mailer: Apple Mail (2.1074) Subject: How to handle hand along data in PHP's parser? From: php@stefan-marr.de (Stefan Marr) Hi internals: Currently, I try to port my Traits patch to the latest version of trunk. Thought about giving you people the chance to play with it again. Unfortunately, I have some trouble with the parser. Think, there must have changed quite something in its internal working. The last time I touched it, I had no problems handing around pointers in $$.u.var, but nowadays, it looks like it is overwritten before it can be used by the other grammar rule. The original idea was to construct as many data during the compilation phase to avoid introducing a whole of a lot new opcodes. But, I am grateful for all suggestion about alternative implementation strategies. For the problem at hand, here some code: trait_adaptation_statement: /* here I emit a opcode to add a new alias or precedence rule to a class */ trait_precedence ';' { zend_add_trait_precedence(&$1 TSRMLS_CC); } | trait_alias ';' { zend_add_trait_alias(&$1 TSRMLS_CC); } ; trait_precedence: /* This rule constructs a struct with the necessary data and should return a pointer to it in $$.u.var */ trait_method_reference_fully_qualified T_INSTEAD trait_reference_list { zend_prepare_trait_precedence(&$$, &$1, &$3 TSRMLS_CC); } ; trait_reference_list: fully_qualified_class_name { zend_init_list(&$$.u.var, Z_STRVAL($1.u.constant) TSRMLS_CC); } | trait_reference_list ',' fully_qualified_class_name { zend_add_to_list(&$1.u.var, Z_STRVAL($3.u.constant) TSRMLS_CC); $$ = $1; } ; trait_method_reference_fully_qualified: fully_qualified_class_name T_PAAMAYIM_NEKUDOTAYIM T_STRING { zend_prepare_reference(&$$, &$1, &$3 TSRMLS_CC); } ; The code is basically unchanged from http://www.stefan-marr.de/traits/traits.patch My problem starts already with trait_method_reference_fully_qualified. I am not able to get the struct which I assigned to $$.u.var in trait_precedence. From what XCode tells me, the memory location of $$ gets overwritten before. Think, it is on the stack somewhere and does not survive long enough to be available in trait_precedence. Any thoughts on that? Many thanks and best regards Stefan