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,
Right, that's what "l" parameter spec is doing, doesn't it? Why convert it
manually?
Because it doesn't know the difference between NULL and 0 if it's a long.
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:
What's "loose long"?
One that doesn't break every script that didn't strictly stay with int over
the last 8 years or so.
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()?
I still don't understand what prevents one from using new parameter
parsing API and why manual conversions doing the same are needed.
See above. Unless you know a way to make IS_NULL work the same way with a
long as it does with a zval anyways.
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
