Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:33888
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 64.97.157.158 cause and error)
Message-ID: <016b01c83ae3$c3acfb60$e6dfc350@foxbox>
Reply-To: "Steph Fox" <steph@zend.com>
To: "Stanislav Malyshev" <stas@zend.com>,
	"Moritz Bechler" <mbechler@eenterphace.org>
Cc: "Marco Kaiser" <marco.kaiser@gmail.com>,
	"'Dirk Thomas / 4wd media'" <dirk.thomas@4wdmedia.de>,
	<internals@lists.php.net>
References: <46.93.08781.F374D474@pb1.pair.com> <474d5320.0d135e0a.43d0.ffffd2b3@mx.google.com> <474D6813.9090606@eenterphace.org> <474DB7F8.5010907@zend.com>
Date: Mon, 10 Dec 2007 04:18:46 -0000
Organization: Zend Technologies
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=response
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] question regarding type hinting parameters of php functions (array_slice)
From: steph@zend.com ("Steph Fox")

Hi Stas,

I just spent most of two evenings looking at this one - so much for an easy 
fix. Read on...

>> the code is
>>
>> if (ZEND_NUM_ARGS() >= 3 && Z_TYPE_P(length_param) != IS_NULL) {
>> length = Z_LVAL_P(length_param);
>> } else {
>> length = num_in;
>> }
>>
>> and afaik should be
>
> I think in fact it should just parse it as long and not as zval - what 
> would be any reason to parse it as zval and then convert to long anyway?

The problem is that this function's always been wrong, so it doesn't really 
care what you throw at it - it just does a silent conversion to long if you 
get it wrong. If you turn the parameter into a long now, there's a good 
chance of breaking a lot of code out there - not least because at present if 
you give array_slice() a length of 0, that's what it (sanely or otherwise) 
takes it to mean. If you fix it, it will see 0 as meaning 'everything to the 
end of the array'. So one of the tests at present is:

var_dump(array_slice($sub_array, 0, 0));

and the expectation is for that to always return:

array(0) {
}

Unfortunately this is far from new behaviour.

As far as the original float issue goes: What's been happening up to now is 
that anything fed in as the third argument gets converted to a long, and now 
it doesn't. Should be easy enough to sort out you'd think, but when you try 
to do:

 /* We want all entries from offset to the end if length is not passed or is 
null */
 if (ZEND_NUM_ARGS() >= 3 && Z_TYPE_P(length_param) != IS_NULL) {
  convert_to_long_ex(&length_param);
  length = Z_LVAL_P(length_param);
 } else {
  length = num_in;
 }

all of a sudden the fourth parameter, preserve_keys, doesn't throw 
zend_parse_parameter() warnings any more, regardless of the type you give 
it. (You tell me...)

There's also the issue of what to do about inappropriate vs appropriate 
input types, since we can't rely on zend_parse_parameters() to psychically 
know that this particular zval is really a loose long kind of thing... so I 
tried:

 if (ZEND_NUM_ARGS() >= 3 && Z_TYPE_P(length_param) > IS_DOUBLE) {
  php_error_docref(NULL TSRMLS_CC, E_WARNING, "integer expected in parameter 
3, %s given", zend_zval_type_name(length_param));
 }

This actually doesn't seem to harm anything, but I bet Dmitry'd say 
otherwise (it probably slows the function right down).

So - not as straightforward as it looks, whatever way you look at it. Maybe 
we should just revert to the old, messy but mostly working code for 
array_slice()?

- Steph