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

Hi Chris, On Fri, January 31, 2014 01:38, Christopher Jones wrote: > > > On 01/27/2014 12:15 PM, 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. >> >> 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. >> >> >> > > Hi Anatol, > > > A quick question: am I right to assume that because this vote has > widespread impact on PHP it needs 2/3 majority per > https://wiki.php.net/rfc/voting ? > > > It's not totally clear that the change is covered by any of the examples > in the voting RFC, but I see the 64 bit project as affecting the language > as a whole (for better or worse!) > catching up on this now as this was delayed by the mail issues. I'm not a native speaker, however what i read here [QUOTE] We also need to ensure, as much as possible, that the decision isn't based on some arbitrary circumstances (such as a temporary marginal majority for a certain school of thought). For these reasons, a feature affecting the language itself (new syntax for example) will be considered as 'accepted' if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get 'accepted'. [/QUOTE] sounds for 50%+1, as it affects not the language itself (no syntax changes, etc.) but its implementation. Even in such an unusual case :) Regards Anatol