On Thu, Jan 30, 2014 at 4:45 PM, Rasmus Lerdorf <[email protected]> wrote:
> On 1/30/14, 2:26 AM, Arvids Godjuks wrote:
>> So, I say you go with the 64 bit improvements for 5.6, set all the things
>> in motion, do the porting docs and make a hell lot of noise about this. I'm
>> willing to help with the information campaign, because this lack of proper
>> 64 bit support has gave me a few "WTF?!" situations when I had to figure
>> out why things do not work and realize it's due to the 64 vs 32 bit issues.
>
> You make it sound like 64-bit vs. 32-bit issues will go away with this
> patch. If you are writing portable code that should run the same
> everywhere you still have to worry about it.
Right, for anything outside php's API&types usage. But that's already
a huge step forward.
> This change does not
> suddenly give you 64-bit integers on a 32-bit platform. The main thing
> this does is it makes 64-bit Windows no longer look like a 32-bit
> platform.
That's not accurate. The main things this patch does is to ensure
correct types for 64bit, ensure that large buffer length can be
managed correctly. It also provides compile time checks for 64bit
types where it was harder to figure them out before. The Windows
support for 64bit integer is a good side effect of this patch and why
we could assign resources to work on it. Please keep in mind that the
initial steps had nothing to do with Windows specific features.
> Other true 32-bit platforms remain 32-bit. It also makes it
> possible to have >2g strings on 64-bit platforms, but this is hopefully
> a rather rare requirement. Imagine running that code on a server with
> MaxClients set to 50...
> I am all for this change, but I still think it is too big of an API
> break for a point release.
I tried a couple of exts, it is really not that big. I will try to
improve the replace.php script to automate more things, especially
around zpp and related variables. That will ease the port of most of
the extensions.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org