Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43081
Return-Path: <chris_se@gmx.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 38479 invoked from network); 17 Feb 2009 21:11:46 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 17 Feb 2009 21:11:46 -0000
Authentication-Results: pb1.pair.com smtp.mail=chris_se@gmx.net; spf=pass; sender-id=pass
Authentication-Results: pb1.pair.com header.from=chris_se@gmx.net; sender-id=pass
Received-SPF: pass (pb1.pair.com: domain gmx.net designates 213.165.64.20 as permitted sender)
X-PHP-List-Original-Sender: chris_se@gmx.net
X-Host-Fingerprint: 213.165.64.20 mail.gmx.net Linux 2.6
Received: from [213.165.64.20] ([213.165.64.20:60139] helo=mail.gmx.net)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id AF/C9-36931-0182B994 for <internals@lists.php.net>; Tue, 17 Feb 2009 16:11:46 -0500
Received: (qmail invoked by alias); 17 Feb 2009 21:11:41 -0000
Received: from p54A14BEC.dip.t-dialin.net (EHLO chris-se.dyndns.org) [84.161.75.236]
  by mail.gmx.net (mp017) with SMTP; 17 Feb 2009 22:11:41 +0100
X-Authenticated: #186999
X-Provags-ID: V01U2FsdGVkX196RSNFEAV6sSmjp9INmCfJiqcZATXS3inVYyUb0B
	ahvy5i5s9kOIWO
Received: from [192.168.0.175] (HSI-KBW-082-212-059-033.hsi.kabelbw.de [82.212.59.33])
	by chris-se.dyndns.org (Postfix) with ESMTP id 59B2C683F;
	Tue, 17 Feb 2009 21:57:54 +0100 (CET)
Message-ID: <499B2842.1030609@gmx.net>
Date: Tue, 17 Feb 2009 22:12:34 +0100
User-Agent: Thunderbird 2.0.0.19 (X11/20081209)
MIME-Version: 1.0
To: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@php.net>
CC: Dmitry Stogov <dmitry@zend.com>, 
 PHP Internals <internals@lists.php.net>
References: <1234904343.17605.35.camel@goldfinger>
In-Reply-To: <1234904343.17605.35.camel@goldfinger>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-FuHaFi: 0.7
Subject: Re: [PHP-DEV] ZEND_USER_OPCODE_CONTINUE
From: chris_se@gmx.net (Christian Seiler)

Hi Johannes,

> 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.

Isn't that expected behaviour? If a normal opcode handler does not
increase the opline, simply returning will also cause re-execution of
the same handler again and again. Why should it be different for user
opcode handlers?

Regards,
Christian