Re: [VOTE] 64 bit platform improvements for string length and integer

From: Date: Tue, 28 Jan 2014 20:56:46 +0000
Subject: Re: [VOTE] 64 bit platform improvements for string length and integer
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message 


On 01/28/2014 12:36 PM, Martin Keckeis wrote:

Am 28.01.2014 21:24 schrieb "Nikita Popov" <[email protected]>:


On Mon, Jan 27, 2014 at 9:15 PM, Anatol Belski <[email protected]> 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.

Thanks for the constructive discussions on this RFC, support and

testing.

The vote begins Monday, 27 January 2014, 21:30 CET and ends Monday, 03
February 2014, 21:30 CET.



Just to clarify my vote: I voted "No" on the RFC, but only because I think
the major extension source API break is better suited to PHP 6 than PHP
5.6. I fully support merging this into master, as the first change for PHP
6.

Nikita


Sadly...
(From a long waiting Php user, who dont want to wait 2-3 years...)



The extension compatibility issue is not insignificant.  Each voter
will have a different idea of how best to take PHP forward while
keeping the current user base happy.

Personnaly, I'd be glad to see the size_t_and_int64 vote halted until
PHP 6 is discussed a little more.  This would give a clearer idea of
what BC breakages are likely in each release, and what the various
release timeframes are.

If the PHP 6 discussion doesn't happen or conclude quickly, then the
size_t_and_int64 vote can be restarted in time for any merge to 5.6.

Work on size_t_and_int64 and SAPI obsoletion etc should continue ready
for which ever branch it will be merged to.

I think I'm the only one (outside Anatol et al) actively looking at an
extension the new branch and have committed to it.  I've some more
OCI8 patches pending, and more investigation to do.  And then the
extension needs to be made compatible with older PHP releases.  In
summary: migration is not a search and replace operation.

Chris

-- 
[email protected]  http://twitter.com/ghrd
Free PHP & Oracle book:
http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html

Thread (132 messages)

« previous php.internals (#71701) next »