Re: [RFC] 64 bit improvements, open questions

On Thu, Jan 23, 2014 at 12:38 PM, Derick Rethans <derick@php.net> wrote: > On Wed, 22 Jan 2014, Christopher Jones wrote: > >> On 01/22/2014 12:20 AM, Anatol Belski wrote: >> > >> > as the discussion phase for this RFC nears to the finish and the >> > patch itself is huge, I'd like to use the last chance to discuss the >> > open questions and concerns. Here are once more the links to the RFC >> > (with several updates) and the porting guide >> > >> > https://wiki.php.net/rfc/size_t_and_int64 >> > >> > http://git.php.net/?p=php-src.git;a=blob;f=compat/PECL_PORTING;hb=refs/heads/str_size_and_int64 >> > >> > The big open question from the previous discussion is how to handle >> > changed ZPP formats. The way I've suggested in the porting doc is >> > using ternary operator like (COMP ? "l" : "i"). Another way were >> > to >> > put the old ZPP formats "lLsp" back and make them redundant to the >> > new ones "iISP". Both ways have their pro and contra, the second >> > variant isn't done, but can be done quickly. >> >> With 22 lines of compatibility macros borrowed from compat/compat.h, I >> can make the "size_t_and_int64" branch of OCI8 compile with PHP >> 5.5. Making ZPP call changes to fix the formats would give a very much >> fuglier code base. There are 86 calls to ZPP in OCI8 (not all would >> need changing). > > That would make me a sad panda, I mean, having to #ifdef lots of ZPP > calls. Please try to avoid this necessity. As the 64-bit branch is > really most important for the Windows port—most Unix-like users run on > 64-bit already anyway—the difficulty of supporting it should not be > pushed on already existing extensions. Yes, that's one of the open questions. I think we can solve the zpp issue by using the same. However some changes will be required and should be BC, especially for size_t, as we really have to use it. I am not sure yet about the int64 usage vs long without too much impact. It is especially important as long usage is really not the way to go. It is also very important to keep in mind that this patch is not only about improving windows 64bits support, there is much more behind that. Get rid of int for buffer size, right usage of 64bit integers, it will drastically reduce the 64bit bugs (security one included). Also about the PECL extensions problem, no matter which solution is chosen, it is really easy to port them. The "people won't be able to use pecl exts because they are not available" argument is somehow pointless. If maintainers do not port their extension to the latest PHP version within a couple of months after its release, or even during the release phases, they won't do it for the next version either. We can't delay a change forever because of them. Also my experience is that most used and maintained extensions are ported very quickly, during the release phases. Dead cows remain dead. Cheers, -- Pierre @pierrejoye | http://www.libgd.org