RE: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string length and integer

From: Date: Wed, 14 May 2014 08:31:33 +0000
Subject: RE: [PHP-DEV] [VOTE] [RFC] 64 bit platform improvements for string length and integer
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-74165@lists.php.net to get a copy of this message
I agree, and I’m not suggesting we ignore it; I just pointed out it makes no sense that such a drastic low-level change will be forced on those who effectively maintain the low-level engine for all of us. I don’t have a magical solution on how to solve it at this point. I did suggest two solutions to the situations within the current voting process: 1. Clearly expressing the concerns Dmitry has about this patch in the Performance section, so that at least people know what’s on the table; And add another option – the option – the one that has the true userland implications (the parts related to IS_LONG), and mention clearly that this one will come with no meaningful performance (memory/CPU) drawbacks. 2. If the authors of the RFC object (which is within their right, of course) – appealing to voters to vote ‘no’ on this one, and create another RFC for the IS_LONG parts. Zeev Even though that I agree, that our current voting process is suboptimal, but I would rather see it fixed instead of ignoring the rules when it is inconvenient/plain wrong. What I do think is wrong with the current rfc, is that it states that it needs only 50%+1 of the votes for acceptance. The patch is big, it will affect every php installation (eg. not just some platforms), it changes the Zend Engine, and it requires some non-trivial effort from the extensions to support it, so even though that the direct impact on the userland isn't that big (code with long strings etc. which would fatal will now starts working, big numbers will overflow differently, etc.) I think it still mandates a 66%+1 vote. Just my 2 cents. -- Ferenc Kovács @Tyr43l - http://tyrael.hu

« previous php.internals (#74165) next »