Yes, i understand.
It was interesting for me -
how i can decrease false positive and others by improvings on current script.
If there will be not GSoC participant for this project,
possibly i can do it.
Also base questions, which will be asked in any case, are still alive:
>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.
2008/3/12, Nuno Lopes <[EMAIL PROTECTED]>:
> 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" <[EMAIL PROTECTED]>
> To: <[email protected]>
> 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
>
>
--
Greetings,
Alexandr Savchuk
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
