One more thing.

The patch has problems with "interactve mode" (php -a).

Thanks. Dmitry.

> -----Original Message-----
> From: Dmitry Stogov [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, November 24, 2005 12:54 PM
> To: 'Sara Golemon'; internals@lists.php.net
> Cc: Andi Gutmans; Zeev Suraski; Stanislav Malyshev; Marcus 
> Boerger; Wez Furlong; Derick Rethans; Andrei Zmievski; Jani 
> Taskinen; Rasmus Lerdorf
> Subject: RE: [PHP-DEV] Re: Labeled Breaks (not the G-word)
> 
> 
> Hi Sara,
> 
> I didn't like "goto" in PHP, but after looking in this patch 
> I see that limited "goto" can work.
> 
> 1) The new syntax makes mess for me.
> "break" is a statement that exits from loop or switch, now we 
> make a "goto" statement but name it "break". I belive that if 
> we really implement goto (even with some limitations) we 
> shuld name it "goto", but not "break". (changed in attached patch).
> 
> 2) After (1) I don't see any reason in limitation to jump 
> only down, if we can jump up as well. (the limitation is 
> removed in attached patch).
> 
> 2) Your patch doesn't care about freeing loop variables and 
> we got a memory leaks in the following example (this is fixed 
> in attahed patch).
> 
> <?php
> foreach (array(1,2,3) as $v) {
>   break LABEL;
> }
> LABEL:
> ?>
> 
> 3) You can declare one LABEL twich. This should emit 
> comilation error. (this is fixed in attached patch).
> 
> 4) Keeping "labels" field in op_array after compilation make 
> not sense as it used only during compilation and not during 
> execution. (this is fixed in attached patch) May be we should 
> place this HashTable somewere outside of op_array.
> 
> Now I don't see inconsistencies.
> But I still not sure that PHP needs "goto".
> 
> Thanks. Dmitry.
> 
> > -----Original Message-----
> > From: Sara Golemon [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, November 24, 2005 8:03 AM
> > To: internals@lists.php.net
> > Subject: [PHP-DEV] Re: Labeled Breaks (not the G-word)
> > 
> > 
> > Set of tests available too now:
> > http://libssh2.org/patches/labeled_break_tests.tgz
> > 
> > It can be untarred from the root of a PHP dist and it'll unfold into
> > Zend/tests/break/
> > 
> > > http://libssh2.org/patches/labeled_break.diff
> > >
> > > A few notes about the implementation:
> > >
> > > * The parser is modified slightly to catch T_BREAK 
> T_LNUMBER ';' and 
> > > T_BREAK T_STRING ';' specifically.  This is in-line with the
> > decision to remove
> > > the
> > > ability to jump to variable targets.  e.g. `break $foo;`
> > will result in an
> > > E_PARSE.
> > >
> > > * current break container is moved from op1.u.opline_num to
> > > extended_value (This means updating continue; as well)
> > >
> > > * op1 is used to store the label's name until pass_two(), at that
> > > point
> > > it's
> > > converted to a jmp_addr.  Non-labeled breaks leave op1 
> > unused and jmp_addr
> > > explicitly set to NULL
> > >
> > > * zend_brk opcode handler updated to use op1->u.jmp_addr if
> > available
> > > (labeled breaks), or el->brk (numbered breaks) if not.
> > zend_brk and
> > > zend_cont both updated per current break container change above.
> > >
> > > * Labeled breaks must target the same break container or
> > higher within
> > > the same op_array, and must only jump "forward" in
> > execution.  These
> > > checks are handled in pass_two() which is the earliest
> > point at which
> > > all labeled are declared.
> > >
> > > * Label hash is only allocated/initialized if labels are declared.
> > >
> > > Known Issues:
> > >
> > > * When an error is thrown from pass_two(), the error 
> message states
> > > it's
> > > in
> > > Unknown on line 0.  Gotta find a better way to handle that....
> > >
> > > * This adds an element to zend_op_array so be sure to either `make
> > > clean`
> > > or
> > > at least `touch Zend/*.c` after applying it otherwise 
> you'll be in 
> > > segfault
> > > country.
> > >
> > > -Sara
> > 
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> > 
> 
> 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to