Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71833
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pthreads.org from 209.85.215.45 cause and error)
Message-ID: <52EB681A.405@pthreads.org>
Date: Fri, 31 Jan 2014 09:08:42 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: Pierre Joye <pierre.php@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAEZPtU6egDoEYaBKjTRvPXGOpbrmdeTU6E2p+=yzk745AQc_Vw@mail.gmail.com> <52EB61BB.5030005@sugarcrm.com>
In-Reply-To: <52EB61BB.5030005@sugarcrm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] int64/size_t options votes clarification
From: pthreads@pthreads.org (Joe Watkins)

On 01/31/2014 08:41 AM, Stas Malyshev wrote:
> 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.
>

 > My personal preference for now is to make this change base for PHP 6
 > branch.

+1000 ... this is the only option that really makes sense ...

Cheers
Joe