Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:72122
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
Message-ID: <c3fa4f7710f1c4594386859cd15907dd.squirrel@webmail.klapt.com>
In-Reply-To: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
References: <e0681b3331094323d383a048471790f8.squirrel@webmail.klapt.com>
Date: Mon, 3 Feb 2014 22:10:19 +0100
To: "Anatol Belski" <ab@php.net>
Cc: "PHP Developers Mailing List" <internals@lists.php.net>,
 "Matt Ficken" <mattficken@php.net>,
 "Stephen A. Zarkos" <szarkos@php.net>
User-Agent: SquirrelMail/1.5.2 [SVN]
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string length
 and integer
From: anatol.php@belski.net ("Anatol Belski")

On Mon, January 27, 2014 21:15, Anatol Belski wrote:
> https://wiki.php.net/rfc/size_t_and_int64
>
>
> There was two big questions regarding the compatibility. Those open
> questions appeared in the discussions are reflected in the reworked RFC.
>
> First question, the possibility to keep the old zend_parse_parameters()
> specs 'l', 'L', 's', 'p' along with new 'i', 'I', 'S', 'P'. Keeping the old
> zpp specs will for sure minimize the porting effort for the PECL
> extensions, but might lead to confusion (like people might think ‘l’
> still expects ‘long’ and not ‘php_int_t’). Please use the yes/no Vote 3 to
>  decide whether the ‘l’, ‘L’, ‘s’, ‘p’ have to stay supported.
>
> Second question, the macro renames for LONG<>INT, STRLEN<>STRSIZE, etc.
> The reason for such renamings was to ensure source level incompatibility
> on compile time. However this might have a negative effect on the porting
> effort (despite the porting tools). Please use the yes/no Vote 2 to
> decide whether the old macro names have to be kept.
>
> The Vote 1 is the main vote for this patch. The both Votes 2 and 3 are
> merely to decide about the semantical replacements choosen for the patch.
> Should the Votes 2 and 3 result in reverting of that semantical changes,
> the essential patch part about the 64 bit support will not be hurt.
> Reverting to old macro names or zpp specs is only the naming issue.
>
>
> Removal of the dead SAPIs is isolated in a separate RFC and can be
> considered to another time.
>

The RFC was rejected.

Thanks for votes and constructive discussion. Based on the feedback in
this thread, this RFC will be resurrected anytime soon.

Best regards

Anatol