On Wed, Aug 27, 2014 at 8:51 AM, Anatol Belski <anatol....@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
