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

On 02/03/2014 01:10 PM, Anatol Belski wrote:

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

Hi Anatol, Thanks for all your work. I look forward to a quick vote on whether to include it in PHP 5.7 or PHP 6.0. However, it would be useful to first know the schedule of those releases, and the branching strategy. It would be good to get your patch into a branch that everyone is working on ASAP. If your patch is approved for PHP 6.0 then I'm sure that you will be a driving force in making sure PHP 6.0 stays on track. In fact, I can foresee you becoming one of the PHP 6 RMs. Chris -- christopher.jones@oracle.com http://twitter.com/ghrd Free PHP & Oracle book: http://www.oracle.com/technetwork/topics/php/underground-php-oracle-manual-098250.html