Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15108
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <4216B594.1050504@akbkhome.com>
Date: Sat, 19 Feb 2005 11:42:12 +0800
User-Agent: Mozilla Thunderbird 0.8 (X11/20040926)
MIME-Version: 1.0
To: Sara Golemon <pollita@php.net>
CC: internals@lists.php.net
References: <005801c5156b$ae0711b0$0201a8c0@gabriel> <855185390.20050218092558@marcus-boerger.de> <008701c515a7$4fec38d0$0201a8c0@gabriel> <20050218121817.30870.qmail@lists.php.net> <00c001c515d4$840fdf90$0201a8c0@gabriel> <frederic.lecointre@burnweb.net> <20050218231740.23365.qmail@lists.php.net> <20050219013017.10131.qmail@lists.php.net>
In-Reply-To: <20050219013017.10131.qmail@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] function proposal - php_check_syntax_string
From: alan@akbkhome.com (Alan Knowles)

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 
>
>  
>