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

Am 28.01.2014 21:24 schrieb "Nikita Popov" <nikita.ppv@gmail.com>: > > On Mon, Jan 27, 2014 at 9:15 PM, Anatol Belski <ab@php.net> 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...)