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

On Fri, Jan 31, 2014 at 9:21 PM, Zeev Suraski <zeev@zend.com> wrote: > > -----Original Message----- > > From: Johannes Schlüter [mailto:johannes@schlueters.de] > > Sent: Friday, January 31, 2014 2:55 PM > > To: Ulf Wendel > > Cc: internals@lists.php.net > > Subject: Re: [PHP-DEV] [VOTE] 64 bit platform improvements for string > > length and integer > > > > On Fri, 2014-01-31 at 13:41 +0100, Ulf Wendel wrote: > > > Am 31.01.2014 13:36, schrieb Johannes Schlüter: > > > > I think adding this patch to 5.x therefore would be quite some > > > > bending of that rule and that combined with the fact that it is late > > > > makes me believe that proposing this for 5.6 is illegal. > > > > > > Are you saying the RFC is 'illegal' ? If the subject proposed is not > > > allowed, it would make litte sense collecting votes. > > > > I think the RM has to reject this from 5.6 independently from the voting > > result as he is bound by the release process RFC. > > > All, > > I have to add something here. > > Many of the people voting on that RFC have never ever contributed as much > as > a single line of code into the PHP source tree, and a couple have literally > contributed low-single-digit patches. > Incidentally, as far as I could tell, all of them[*] voted in favor of the > proposed changes (i.e. source compatibility breakage). > > Even though having non-code-contributors makes a lot of sense for decisions > regarding the language's features and we built in support for it in the > voting RFC, in my opinion, it makes no sense at all for people who have no > stake at the development of the language's source code to weigh in on how > that code is written. Personally I didn't expect we'd be voting on things > like that (implementation style) back when I was involved in the voting > RFC, > but perhaps it's time to amend it a bit. > > If you fall in that category, please do the right thing and delete your > vote. > Hi Zeev, I think that this vote also makes sense for maintainers of PECL extensions as they will need to do lots of work. I am aware what the patch does and how much work I will need to do in my extensions. I actually did the openssl part of the 64bit patch just to see what changes will be required for my crypto ext which also is an openssl wrapper. And yes it will require lots of changes. Probably the most time consuming part of the porting (that wasn't mentioned here) is looking to the different versions of the libs and testing how it affects the extension. There are sometimes types changes between different versions of libs which can result in nasty bugs. For example the size_t change could even result to some security issues if it's not handled properly. The reason why I voted YES is that I don't see any difference if the patch is merged now or in the future. The work will need to be done anyway. It will just require more time that will need to be spent on maintaining the 64bit branch if the patch is merged later. Thanks Regards Jakub