Markus,
The problem is that compile_string() will add functions and classes to
PHP's global structures. Also, if there's a parse error it can leave the
internal compiler structures in an unstable state.
I can't think of any quick and easy way of support this kind of lint
feature nor eval() recovery.
Andi
At 11:59 AM 6/21/2002 +0200, Markus Fischer wrote:
> Hi,
>
> I think you're idea is pretty good, however not the way you
> engaged the current behaviour imho.
>
> PHP also supports 'lint'ing of source code aka. checking for
> parserer errors. It's just a few minutes work to provide the
> same functionality for a new function:
>
> $retval = lint($code);
>
> This would also throw parserer errors right at you, if you
> don't want, use '@' to supress it. It could be named
> 'eval_test' as someone on IRC (hey guys, btw:) suggested, or
> an optional argument to eval() to do only linting of the
> source, whatever.
>
> I've attached a small patch against
> Zend/zend_builtin_functions.c from CVS a few days ago (but it
> can be done everywhere, e.g. ext/standard ). I didn't
> commited it because a) I wasn't unsure if ppl want it and b)
> if it's the proper way to do it that way ("it works for me").
>
> Any of the developers care reviewing, (fixing,) commiting ?
> :)
>
> - Markus
>
>
>On Fri, Jun 21, 2002 at 08:57:43AM -0000, [EMAIL PROTECTED] wrote :
> > From: [EMAIL PROTECTED]
> > Operating system: Any
> > PHP version: 4.2.1
> > PHP Bug Type: Feature/Change Request
> > Bug description: Error Handling for eval()
> >
> > I want to handle Parse_Errors and similar Fatals with my custom error
> > handler when they occur in eval()'d code.
> >
> > This is necessary when i want to execute custom code in my console script
> > and prevent this code from crashing my entire program if there is only a
> > simple typo in there...
> >
> > I have achieved this by a little hack in the "zend_execute.c" but i don't
> > know if this handles any errors right that don't occur in eval'd()
> > code...
> > This is what i changed (to even prevent a segmentation fault)
> > (zend_execute.c, line 1563):
> >
> > if (zend_hash_find(active_function_table, function_name->value.str.val,
> > function_name->value.str.len+1, (void **) &function)==FAILURE) {
> > zend_error(E_USER_ERROR, "Call to undefined function: %s()",
> > function_name->value.str.val);
> > return;
> > }
> >
> > --
> > Edit bug report at http://bugs.php.net/?id=17892&edit=1
> > --
> > Fixed in CVS: http://bugs.php.net/fix.php?id=17892&r=fixedcvs
> > Fixed in release: http://bugs.php.net/fix.php?id=17892&r=alreadyfixed
> > Need backtrace: http://bugs.php.net/fix.php?id=17892&r=needtrace
> > Try newer version: http://bugs.php.net/fix.php?id=17892&r=oldversion
> > Not developer issue: http://bugs.php.net/fix.php?id=17892&r=support
> > Expected behavior: http://bugs.php.net/fix.php?id=17892&r=notwrong
> > Not enough info: http://bugs.php.net/fix.php?id=17892&r=notenoughinfo
> > Submitted twice: http://bugs.php.net/fix.php?id=17892&r=submittedtwice
> > register_globals: http://bugs.php.net/fix.php?id=17892&r=globals
>
>--
>GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
>Did I help you? http://guru.josefine.at/wish_en
>Konnte ich helfen? http://guru.josefine.at/wish_de
>"uhmm.. the dates in the bug db.. aren't they printed a bit wrong, i mean, did
>i miss when we changed to 53 days/month ( +2002-02-53) ? =P - N0v3ll
>
>--
>PHP Development Mailing List <http://www.php.net/>
>To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
