Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36101
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 212.55.154.22 as permitted sender)
Message-ID: <1AE8AAD664AA41C698C28602A42A72AB@pc07654>
To: "Alexandr Savchuk" <a.u.savchuk@gmail.com>,
	<internals@lists.php.net>
References: <8cd3358e0803102200r2047ed33n99766953258de66b@mail.gmail.com>
In-Reply-To: <8cd3358e0803102200r2047ed33n99766953258de66b@mail.gmail.com>
Date: Tue, 11 Mar 2008 19:33:11 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] new version of check_parameters.php
From: nlopess@php.net ("Nuno Lopes")

Hi,

Thanks for working on this. However I don't think more effort should be 
wasted with this script. It's a bogus approach to the problem and it will 
always generate many false-positives (disclaimer: I'm the author of the 
original script and it was like a POC).
Thus my idea is to move along to use a real C/C++ front-end and perform the 
things correctly. For example, the new LLVM's clang frontend is really easy 
to work with. That's why I've proposed this for a gsoc project. It's fairly 
easy for someone with little compiler knowledge, yet it gives enough work to 
be a gsoc project.

Regards,
Nuno


----- Original Message ----- 
From: "Alexandr Savchuk" <a.u.savchuk@gmail.com>
To: <internals@lists.php.net>
Sent: Tuesday, March 11, 2008 5:00 AM
Subject: [PHP-DEV] new version of check_parameters.php


> Hello developers.
>
> I saw some days ago that
> there is need in rewriting of check_parameters.php to be less
> false-positive and so on...
>
> So i wrote new version - based on state machines _and_ regex.
> Base checks are the same, only reporting is improved.
>
> There is simple comparision:
>
> -- on old version my php-5.2.5 source old util gives ~180 problems
> (excluding optional, non optional params initialization,
> reporting_level is setted up to 5):
>
> # php ./scripts/dev/check_parameters.php /xxxx/php5.2-200803061530  |
> grep -iv 'optional var not initialized' | grep -iv 'not optional var
> is initialized' > ./old1.log
> # wc -l ./old1.log
> 181 ./old1.log
>
> new gives ~150 problems :)
>
> # php /check_code.php -v 5 /xxxx/php5.2-200803061530 |grep -iv
> 'OPTIONAL var IS NOT' | grep -iv 'NOT OPTIONAL var IS initialized' >
> /new1.log
> # wc -l /new1.log
> 147 /new1.log
>
> Some problems are unavoided:
> - external variable definition (~60)
>    * 'php_com_variant_class_entry'  - 11 reports
>    * 'date_ce_timezone'  - 2 reports
>    * 'oci_lob_class_entry_ptr' - 26 reports
>    * 'text**' - 7 reports
>    * 'oci_coll_class_entry_ptr'  - 10 reports
>    * 'zend_ce_traversable' - 3 reports
>    * others ...
> - too complex cases of parsing ( can be fixed by hacks but it's wrong...) 
> (~5)
>
> , others will be solved by more correct parsing
> and some will be fixed in source code (i think :) ), for example:
>
> ext/iconv/iconv.c [] iconv_mime_encode : field_value: expected
> "char**" but got "const char**" [3]
> ext/mysqli/mysqli_nonapi.c [] mysqli_connect : hostname_len: expected
> "int*" but got "unsigned int*" [2]
> ext/mysqli/mysqli_nonapi.c [] mysqli_connect : username_len: expected
> "int*" but got "unsigned int*"[4]
> ext/mysqli/mysqli_nonapi.c [] mysqli_connect : passwd_len: expected
> "int*" but got "unsigned int*" [6]
> ext/mysqli/mysqli_nonapi.c [] mysqli_connect : dbname_len: expected
> "int*" but got "unsigned int*" [8]
> ext/mysqli/mysqli_nonapi.c [] mysqli_connect : socket_len: expected
> "int*" but got "unsigned int*" [11]
> ext/openssl/openssl.c [] openssl_seal : the '/' specifier cannot be
> applied to 'a'
> ext/pgsql/pgsql.c [] pg_field_table : the '!' specifier cannot be applied 
> to 'b'
> ext/pgsql/pgsql.c [] pg_copy_from : the '/' specifier cannot be applied to 
> 's'
> ext/pgsql/pgsql.c [] pg_meta_data : table_name_len: expected "int*"
> but got "uint*" [3]
> ext/pgsql/pgsql.c [] pg_convert : option: expected "long*" but got 
> "ulong*" [5]
> ext/pgsql/pgsql.c [] pg_insert : option: expected "long*" but got "ulong*" 
> [5]
> ext/pgsql/pgsql.c [] pg_update : option: expected "long*" but got "ulong*" 
> [6]
> ext/pgsql/pgsql.c [] pg_delete : option: expected "long*" but got "ulong*" 
> [5]
> ext/pgsql/pgsql.c [] pg_select : option: expected "long*" but got "ulong*" 
> [5]
> ext/standard/streamsfuncs.c [] stream_socket_client : the '!'
> specifier cannot be applied to 'd'
>
> , so i believe final number will be ~70-80 ...
>
> There are also need to do:
> * write tests
> * rewrite dropping comments from code
> * return missed current_line function
> * replace other regexes by statemachines where it is possible
> * improve more maintainability
> * write docu
> * smth else ?
>
> So it's not last version...
> But please check it if you have time. You can see utility on [1]
>
> (I don't creare patch because of it is the same as downloading new
> version - too many changes)
>
> Also i have questions:
> 1. in many problem reports there are unsigned int (or uint, or ulong
> -> long or smth else) to int assigning. Is it safe ? If yes, then i
> need to process this in code
>
> 2. There are really many problem reports about "optional var is not 
> initialized"
> Is there a requrement for reporting about it ? And why ?
>
> 3. There are really many problem reports about "not optional var is 
> initialized"
> Also in most part of these cases not optional var is inialized by null
> value. Why is this requrement ? And why ?
>
> 4. there is code like:
>
> // separate_zval_if_not_ref
> case '/':
>        //FIXME could not understand from why it so ????
>        if ( !in_array($prev_char, array('r', 'z')) ) {
>                self::error("the '/' specifier cannot be applied to
> '$prev_char'");
>        }
> break;
>
> Why ? In readme.parameter_parsing_api docu i can't find any related to
> it information.
>
>
> Links:
> [1] http://sawoy.mylivepage.com/file/?fileid=2830
>
> -- 
> Greetings,
> Alexandr Savchuk