On Sun, Jun 2, 2013 at 11:11 AM, Johannes Schlüter <johan...@schlueters.de> wrote: > > > On Jun 2, 2013, at 8:34, Pierre Joye <pierre....@gmail.com> wrote: > >>> 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. >> >> A new macro will be a good solution, but I would name it what it >> actually is, Z_SIZE_T. > > That's not what it is. It is the length of the string aka. > var.value.str.length as such it should indicate its relation to a string. So > something like Z_STRSIZE is correct (and the name is nice thinking about > Unicode strings where length (characters) != size (bytes))
It is size_t. There is no such thing as unicode or multibyte string length in php but in mbstring, intl or iconv, to name a few. php strings are buffers, and buffers lengths use size_t. This macro (and other) are about extension developers, working in C, not about what its representation in userland. Even if they are closely related, obviously. The day we will have actual multi bytes/unicode strings, we will need a separate length to represent in characters (be multi bytes). Cheers, -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
