Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71829
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.174 as permitted sender)
MIME-Version: 1.0
Date: Fri, 31 Jan 2014 08:45:15 +0100
Message-ID: <CAEZPtU6egDoEYaBKjTRvPXGOpbrmdeTU6E2p+=yzk745AQc_Vw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: int64/size_t options votes clarification
From: pierre.php@gmail.com (Pierre Joye)

hi,

Reviewing the votes and the arguments for the votes (negative or
positive), it seems that there is a little confusion or I miss the
reasoning behind the votes about the options.

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.

In the case this RFC is rejected for 5.6, these options are really not
what is planed to do for 6.x as we should do it the clean way, as
explained in the various discussions here and as many of the
opposition used as argument as well.

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.

Thanks!

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org