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.
OK, great! :)
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
well, it depends. an integer in PHP is a signed long, so probably you want
to stick to this, although in most cases using an unsigned long is safe.
So there's no real answer to that question: It depends.
2. There are really many problem reports about "optional var is not
initialized"
Is there a requrement for reporting about it ? And why ?
yes! an optinal argument may not get initialized. So reading such an
optional argument that the user left unspecified may result in a crash.
However, most of these reports are bogus. The good news is that these
false-positives can be killed with a simple path-sensitive flow-analysis
(really simple in clang).
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 ?
This warning is only displayed if the error reporting level is high, at it
produces too much reports. It is just a help to show dead assigments that
could be removed (because non-optional arguments are garanteed to be
initialized).
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.
Well applying the '/' specifier to 'l' (long) or 'd' (double) doesn't really
make sense. It may even create a memleak on those cases (unconfirmed, but it
seems so).
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
