Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67596
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.169 as permitted sender)
MIME-Version: 1.0
Date: Fri, 31 May 2013 15:11:34 -0400
Message-ID: <CAAyV7nG126YkpOF-EShHbf=4rgX7gQ2VE0ShRh0-50_Yr--h4g@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=bcaec5040c06223bfe04de086249
Subject: 5.NEXT Integer and String type modifications
From: ircmaxell@gmail.com (Anthony Ferrara)

--bcaec5040c06223bfe04de086249
Content-Type: text/plain; charset=ISO-8859-1

Hello all,

I want to start an idea thread (or at least get a conversation going) about
cleaning up the core integer data type and string lengths. Here's my ideas:

1. Change string length in the ZVAL from int to size_t
 - http://lxr.php.net/xref/PHP_5_5/Zend/zend.h#321
2. Change long in the ZVAL  (lval) to a system-determined 64bit fixed size

There are two reasons for this. First, on VS compiles (windows), the
current long size is always 32 bit. So that means even 64 bit compiles may
or may not have 64 bit ints.

The second reason is that right now PHP can't really handle strings >= 2^31
characters even on 64 bit compiles. The problem gets pretty comical:

$ php -d memory_limit=499g -r "\$string = str_repeat('x',pow(2, 32)) .
str_repeat('x', pow(2,4)); var_dump(strlen(\$string));"
int(16)

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.

Likewise we can do the same for the long data type (Z_LVAL() returns a
long, and Z_PHPLVAL() returns a php_long (which is a typedef of a 64 bit
compiler specific type).

It'll also require 2 new zend_parse_parameters types (one for php_long and
one for the string len using size_t instead)...

Additionally, I'd propose a set of central helpers to cast back and forth
between php_long and long, as well as int to size_t (with overflow checks,
allowing us to do errors on detected overflows instead of silently ignoring
them as today).

It would be a *gigantic* patch, but the userland effects should be minimal
(the only changes would be supporting longer strings, and consistent 64 bit
int support). The performance considerations should be minimal for
non-legacy code (as both would still be using native data types)...

What do you think? What am I missing from this? Or is this just a horrific
idea (given the current implementation details)...?

Anthony

--bcaec5040c06223bfe04de086249--