Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71424
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zend.com from 74.125.82.46 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAF+90c8mDBqe+E=cWxpD-U48Ho0QV3iHiwS9pOSEbUn_uZTVnQ@mail.gmail.com>
References: <fa05c43bc2fff5420759e05dee19c99f.squirrel@webmail.klapt.com>
	<CAF+90c8mDBqe+E=cWxpD-U48Ho0QV3iHiwS9pOSEbUn_uZTVnQ@mail.gmail.com>
Date: Thu, 23 Jan 2014 12:42:58 +0400
Message-ID: <CA+9eiLvhRqFAunM8GCpqE5ja2jXKCzFMKdtF0NkBT11nu=36MQ@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Anatol Belski <ab@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01493c32791a7804f09f3a22
Subject: Re: [PHP-DEV] [RFC] 64 bit platform improvements for string length
 and integer
From: dmitry@zend.com (Dmitry Stogov)

--089e01493c32791a7804f09f3a22
Content-Type: text/plain; charset=UTF-8

I completely agree with Nikita.
Why to rename LONG->INT STRLEN->STRSIZE in thousands places?
Why not just define zend_long and zend_ulong to be 64-bit on 64-bit
platforms and use them instead of int, ulint, zend_int, zend_uint, long,
ulong where it's necessary.

Anatol, I understood your point about catching incompatibility code at
compile-time, but I'm not sure if the new features cost such huge code base
changes.

1) 64-bit integers on Windows (they are already 64-bit on other systems)
2) 64-bit string length. I don't think many people are interested in that.
Fortunately, the patch doesn't change the zval size, so it shouldn't make a
lot of harm. However, usage of "zend_size_t" instead of "int" is a bit
annoying. I would change it into the same "zend_long" or "zend_ulong".

Thanks. Dmitry.


On Sat, Jan 11, 2014 at 1:42 AM, Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Fri, Jan 10, 2014 at 3:58 PM, Anatol Belski <ab@php.net> wrote:
>
> > Hi,
> >
> > https://wiki.php.net/rfc/size_t_and_int64
> >
> > The discussion time has come. The work on the feature branch continues.
> > The current patch is stable enough to be discussed.
> >
>
> What is the reason behind the renames of IS_LONG to IS_INT (and Z_LVAL to
> Z_IVAL etc), as well as the renames in zpp (s -> S, etc)? Why can't we keep
> the old names here? That should reduce the amount of ifndefs involved a
> lot, as you'd only have to do it for the type declarations themselves, not
> for every single usage. Or is the point here to intentionally provide a
> maximum amount of BC breakage, so code doesn't "accidentally" continue to
> run (e.g. I think that without the renames extensions could continue to run
> mostly without issue on 32bit.)
>
> Nikita
>

--089e01493c32791a7804f09f3a22--