Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:76902
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <221c660eb11d0f30bb065bbc34e657f4.squirrel@webmail.klapt.com>
References: <62188C5D-C62B-493F-8CB1-9B48C5555131@gmail.com>
	<221c660eb11d0f30bb065bbc34e657f4.squirrel@webmail.klapt.com>
Date: Wed, 27 Aug 2014 09:54:57 +0200
Message-ID: <CAEZPtU5_a-483Uh6AFsByR5SFfh7sFYXoxQi_Qbp2iB_xWiA-A@mail.gmail.com>
To: Anatol Belski <anatol.php@belski.net>
Cc: Tjerk Meesters <tjerk.meesters@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Re: zpp and zend_string
From: pierre.php@gmail.com (Pierre Joye)

On Wed, Aug 27, 2014 at 8:51 AM, Anatol Belski <anatol.php@belski.net> wrote:
> Hi Tjerk,
>
> On Wed, August 27, 2014 07:34, Tjerk Meesters wrote:
>> Hi internals,
>>
>>
>> With the recent merge of int64 the `zend_string` type now uses `size_t`
>> to store its length, but ZPP (and friends) still use `int *` to store the
>> parsed string lengths.
>>
>> http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_API.c#519
>>
>>
> Yep, this is a good question, as that zend_string uses size_t for the
> length now with 'S', but 's' goes the old way. IMHO we should let it be as
> it is, or even enforce 's' length to be exact unsigned 32 bit. And, we
> should check for places where we need the conversion to zend_string -
> those are
>
> - where we work with pure strings in PHP, like substr() for example
> - where the dependency library requieres or supports that
>
> As example - it makes no sense to use zend_string for zlib or ICU, but
> it's fulle justified for iconv.

That's not related to zend_string usage or not but the length of the
string. One function would be safe or allow large string and other
not? That does not sound good.

F.e. ICU uses int32_t, zlib uses uLong (custom type defined to
unsigned long).  For ICU, a overflow check is required before calling.
For zlib, it depends on the size of size_t, but ulong can then be
64bit (as zlib supports large buffer compression). It does not mean
zlib will have large buffer in memory (stream compression f.e.) but it
has to be able to return the size of the in or out.

We have to use size_t here. We have to deal with large string as the
zpp level, or it will be a total mess if some functions accept it and
other not. Just like what we already do with similar issues, size
checks are necessary before calling an external API, raising an
error/failing if the given buffer is too large for a given external
function.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org