Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71830
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.83 as permitted sender)
Message-ID: <52EB61BB.5030005@sugarcrm.com>
Date: Fri, 31 Jan 2014 00:41:31 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAEZPtU6egDoEYaBKjTRvPXGOpbrmdeTU6E2p+=yzk745AQc_Vw@mail.gmail.com>
In-Reply-To: <CAEZPtU6egDoEYaBKjTRvPXGOpbrmdeTU6E2p+=yzk745AQc_Vw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] int64/size_t options votes clarification
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> The option #1 (Keep the old macro names for LONG vs. INT, STRLEN vs.
> STRSIZE, etc.) and #2 (Keep zpp specs l, L, s, p as aliases to i, I,
> S, P), which both drastically reduce code changes or #fidef usage, are
> valid for 5.6 integration.

The first one seems to me relatively tame, at least unless I'm missing
something. I'm not one to give too much importance to precision of
naming of macros, but why not make it easy on people?

The second one, however, seems dangerous - that means if I forget to
convert some function that uses zpp, I get no indication at all, except
for random hard-to-debug crashes when it's used with wrong int type.
The alternative for this is (PHP_NEED_STRSIZE_COMPAT ? "Os|al" :
"OS|ai"), which feels my heart with dread and one of the reasons why I
lean to voting "no", even though I like the idea of the cleanup. But
compared to the alternative, this is a *better* option. Because at least
this would fail fast in the case of trouble and will be discovered if
you have any half-decent tests on your extension. The other way means if
you forget to convert the zpp call and do convert the values involved,
you'd have very interesting debugging session waiting for you.

> For those having voted no for 5.6 and the options, would you mind
> explaining what are your wishes? It will help to move forward, no
> matter the outcome of the votes.

My personal preference for now is to make this change base for PHP 6
branch. We've started talking on 6 anyway, and I don't see it out of the
possible to kick off real feature mapping and even start working on it
this year, and have at least early alphas sometime next year. This would
be our opportunity to break APIs to make them better. If that is not
what happening, what I am afraid of is that people - at least ones that
use custom extensions and work on sizeable products with non-trivial QA
cycles - would treat 5.6 as somewhat a theoretical exercise and would
wait it out for 6 (unless we starve them out by never delivering on it
in next 3-4 years). And that's not a good place for a release to be in.
I like the things done in 5.6, and I like the work Anatol and others
have done on 64-bit cleanup. But I'm afraid that by combining them we'd
harm them both.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227