Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61530
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nebm.ist.utl.pt from 193.136.128.22 cause and error)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Nikita Popov" <nikita.ppv@gmail.com>, "Sara Golemon" <pollita@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <op.whnt7vdjidpuyk@damnation>
 <CAESVnVq7tCP3oCwgyq1BGz8JmoAGUY1anE_TAe2cZeErKNXCBQ@mail.gmail.com>
 <op.whpjg0eqidpuyk@damnation>
 <CAESVnVoTSP-9nXoj1LffgdhXK8L_a7aVbsgy+Z4y9ncku2EVNQ@mail.gmail.com>
 <CAF+90c_WjedgG0zZo5kGqNGUBG7YV0R6S5p-u9Z6y93oBDER2w@mail.gmail.com>
 <CAESVnVrFCgvXodsGL_PMz=84O4x=Zn+BuAZ9TRxVTbj-dAnWPg@mail.gmail.com>
Date: Fri, 20 Jul 2012 01:49:50 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Organization: =?utf-8?Q?N=C3=BAcleo_de_Eng=2E_Biom=C3=A9di?=
 =?utf-8?Q?ca_do_I=2ES=2ET=2E?=
Message-ID: <op.whpwhcv8idpuyk@damnation>
In-Reply-To: <CAESVnVrFCgvXodsGL_PMz=84O4x=Zn+BuAZ9TRxVTbj-dAnWPg@mail.gmail.com>
User-Agent: Opera Mail/12.50 (Linux)
Subject: Re: [PHP-DEV] zend_parse_parameters() improvements
From: glopes@nebm.ist.utl.pt ("Gustavo Lopes")

Em Fri, 20 Jul 2012 00:20:49 +0200, Sara Golemon <pollita@php.net>  
escreveu:

> Okay, well... the main pieces of feedback I'd give on it then is to not
> change the behavior of the '!' modifier.  That's bad BC.  Rather,  
> introduce
> a new modifier for checking if a parameter was passed.  Secondly, make
> these two separate patches as the new modifier is a separate feature from
> the single-arg parameter parsing.
>
> FWIW, there are a few examples of this being handled by defining the
> default value of the parameter to something non-sensical (such as a  
> length
> of -1), then doing zpp with "|l!" would leave the default -1 alone when
> NULL is passed, and you can treat as "not passed".  Granted this is a bit
> of a hack and won't work for all situations.  Your approach is more
> comprehensive, just saying that for many cases it's not strictly needed.
>

Stas managed to confuse you :)

On an implementation level, this has nothing to do with default parameter  
values and unpassed parameters. As always, if you don't pass an argument,  
the pointers you give to zpp won't be touched. The behavior of ! is not  
changed insofar as it was not possible to use it with l, d or b (well  
actually it was ignored, so if anyone used l! their code will break as you  
now have to pass an extra argument, but it was wrong in the first place).

Default parameters and unpassed parameters enter the scene because it's  
idiomatic to pass NULL to have the same effect as not passing that  
parameter.

Consider this hypothetical internal function with signature:

mb_substr(string $str, int $start [, int $length [, string $encoding ]])

Let's also imagine we want that the effect of not passing $length cannot  
be triggered by a specific value of $length (like -1) because the whole  
integer domain is used for something else. We have this check:

if (ZEND_NUM_ARGS() < 3) { /* do special stuff */ }

But now I cannot pass $encoding and not pass $length. I also can't wrap  
the function and pass-through arguments in an easy fashion.

An idiomatic solution for this is to use NULL as a special value. In  
userspace:

function mb_substr($str, $start, $length=NULL, $encoding=NULL) {
     if ($length === null) { /* do special stuff */ }

However, the same is not possible with zpp because if we use 'l' and we  
send NULL, we'll get 0, which we cannot distinguish from an actual 0 being  
passed (or false, etc.).

The first commit in the branch solves this problem. We could write:

char *str, *encoding = NULL;
int str_len, encoding_len;
long start, length;
zend_bool length_is_null = 0;
zend_parse_parameters(..., "sl|l!s!, &str, &str_len, &start,
     &length, &length_is_null, &encoding)

Then we have length_is_null == 0 <=> $length was not passed or NULL was  
its value (just like the userland check above).

-- 
Gustavo Lopes