Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:36111
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: <6DD2826BA6C2482EB0E907E9341D5218@pc07654>
To: "Alexandr Savchuk" <a.u.savchuk@gmail.com>
Cc: <internals@lists.php.net>
References: <8cd3358e0803102200r2047ed33n99766953258de66b@mail.gmail.com> <1AE8AAD664AA41C698C28602A42A72AB@pc07654> <8cd3358e0803121517j5ce1794fo58a8f8d37e61cfe2@mail.gmail.com>
In-Reply-To: <8cd3358e0803121517j5ce1794fo58a8f8d37e61cfe2@mail.gmail.com>
Date: Wed, 12 Mar 2008 22:55:35 -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")

> 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