zpp and zend_string View as Markdown

Hi Tjerk,

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