# zpp and zend_string

- Thread: https://externals.io/message/76896
- Original archive: https://news-web.php.net/php.internals/76896
- Started by Tjerk Meesters on 2014-08-27T05:34:59+00:00
- Messages: 4
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #76896 — Tjerk Meesters — 2014-08-27T05:34:59+00:00

URL: https://externals.io/message/76896#76896

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

This look like an oversight. Will this be fixed as well?

---

## #76899 — Anatol Belski — 2014-08-27T06:51:11+00:00

URL: https://externals.io/message/76896#76899 · In reply to: #76896

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.

Regards

Anatol

---

## #76902 — Pierre Joye — 2014-08-27T07:54:57+00:00

URL: https://externals.io/message/76896#76902 · In reply to: #76899

> Hi Tjerk,
>
> 
> > […]
> 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

---

## #76906 — Andrea Faulds — 2014-08-27T11:53:41+00:00

URL: https://externals.io/message/76896#76906 · In reply to: #76896

> 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
> 
> This look like an oversight. Will this be fixed as well?

While we’re at it, why does zpp take an int* for param_count when you use *? The type of param_count in zend_fcall_info is uint32_t (formerly zend_uint), and if you’re using *, that’s the struct member you’ll be giving zpp a pointer to.

--
Andrea Faulds
http://ajf.me/