Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43082
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 83.243.58.134 as permitted sender)
To: Stefan Esser <stefan.esser@sektioneins.de>
Cc: Dmitry Stogov <dmitry@zend.com>, PHP Internals <internals@lists.php.net>
In-Reply-To: <499B26AC.8050905@sektioneins.de>
References: <1234904343.17605.35.camel@goldfinger>
	 <499B26AC.8050905@sektioneins.de>
Content-Type: text/plain
Date: Tue, 17 Feb 2009 22:12:44 +0100
Message-ID: <1234905164.17605.47.camel@goldfinger>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] ZEND_USER_OPCODE_CONTINUE
From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Stefan, 

On Tue, 2009-02-17 at 22:05 +0100, Stefan Esser wrote:
> > while implementing a small toy extension (see [1]) I found out that
> > ZEND_USER_OPCODE_CONTINUE seems to misbehave as it doesn't go to the
> > next opcode so I ended up in an endless loop executing the same opcode
> > again and again.
> 
> I guess that is exactly the required behaviour. How else do you want to
> implement an user opcode that transfers control to another opline, like
> a special kind of jump opcode.

ZEND_USER_OPCODE_DISPATCH_TO sounds like the way to do that. But we have
no clean API to set the next opcode and CONTINUE is documented as 

#define ZEND_USER_OPCODE_CONTINUE   0 /* execute next opcode */

talking about the "next" one - so /some/ cleanup is needed.

johannes