Re: [RFC] 64 bit improvements, open questions

From: Date: Thu, 23 Jan 2014 11:38:00 +0000
Subject: Re: [RFC] 64 bit improvements, open questions
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-71432@lists.php.net to get a copy of this message
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. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine

« previous php.internals (#71432) next »