Anthony Ferrara <ircmax...@gmail.com> wrote:
>1. Change string length in the ZVAL from int to size_t
> - http://lxr.php.net/xref/PHP_5_5/Zend/zend.h#321

This would be good but a lot of work and an hard to track engine change ...

>2. Change long in the ZVAL  (lval) to a system-determined 64bit fixed
>size

Didn't somebody do a great chunk of the work to add arbitrary integer support? 
64bit is nice, arbitrary would be nicer (and both have issues in situations 
where we pass the PHP int to an external library expecting an int or long or 
such ...)

>Obviously there's a pretty significant ABI break here. I propose a
>"tweak" of the Z_* macros to "fix" that. Basically, Z_STRLEN() will cast the
>result to an int. This is the same behavior as today, and will mean that
>existing extensions continue to function exactly as today. But new extensions
>(and elsewhere in core) can use a new macro Z_STRSIZE() which will return
>the native size_t.

This will give strange results and potential bugs with strings on systems where 
MAX_SIZE_T > MAXINT when a user passes a string longer than MAXINT (luckily 
this, on all relevnt systems) means more than 2GB data, which usully should be 
hard to do for an external attacker and be prevented by memory_limit etc. 

>It would be a *gigantic* patch, but the userland effects should be
>minimal (the only changes would be supporting longer strings, and consistent 64
>bit int support). The performance considerations should be minimal for
>non-legacy code (as both would still be using native data types)...

History shows that such gigantic patches are often not finished and done as 
people underestimate the size of PHP and the fact that all etensions have to be 
checked which for this case means checking each external lib for their correct 
type for all their functions etc ... but I don't wan to stop you, I'm happy if 
you do this :-) (while I'm also happy about everybody spending time on fixing 
bugs instead of adding such high-risk changes  ;-))

johannes

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to