Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67604
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAAyV7nG126YkpOF-EShHbf=4rgX7gQ2VE0ShRh0-50_Yr--h4g@mail.gmail.com>
References: <CAAyV7nG126YkpOF-EShHbf=4rgX7gQ2VE0ShRh0-50_Yr--h4g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: Sun, 02 Jun 2013 08:52:29 +0200
To: Anthony Ferrara <ircmaxell@gmail.com>,"internals@lists.php.net" <internals@lists.php.net>
Message-ID: <3e1b2d12-97cd-4928-b526-0a4b9d443ca5@email.android.com>
Subject: Re: [PHP-DEV] 5.NEXT Integer and String type modifications
From: johannes@schlueters.de (=?ISO-8859-1?Q?Johannes_Schl=FCter?=)



Anthony Ferrara <ircmaxell@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