Re: function proposal - php_check_syntax_string

From: Date: Sat, 19 Feb 2005 03:42:12 +0000
Subject: Re: function proposal - php_check_syntax_string
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-15108@lists.php.net to get a copy of this message
I guess swapping out the compiler and executer globals before /after the compile call wont work? egs = executor_globals cgs = compiler_globals compile_string / file etc. efree(executor_globals); efree(compiler_globals); executor_globals = egs; compiler_globals = cgs; obviously if this is the case with files, you probably want parse multiple files at once to ensure things like 'extends' work. It would be nice to move to a more serializeable format of opcodes in PHP6, so we can make the compiler code dl()'able :) Regards Alan Sara Golemon wrote:
Is there possibilty to run syntax check only with compil_string in zend_language_scanner.c (or something else) instead of removing the introduced code?
     
No. At least I don't know a how (but I don't know everything about the engine) The only thing I currently can think of is using the scanner to tokenize the string (using zend_prepare_string_for_scanning() and lex_scan()) but such a solution would only reject totally bogus code and wouldn't tell you wether the code was valid...
Function/Class declaration is part and parcel to the current ZE parser. A global *could* be added to restrict adding functions/classes to EG(function_table)/EG(class_table), something like CG(register_functions) = 0 and CG(register_classes) = 0 or something. It'd only be one extra if statement per declaration so it certainly doesn't *seem* all that bad. It's up to the Zend folks though. As mentioned earlier, parsekit has a hackish workaround by comparing the hash tables before/after compilation and to my knowledge it hasn't had any major issues, so it's not a *necessary* thing. -Sara


« previous php.internals (#15108) next »