Hi Derick, On Fri, June 7, 2013 14:06, Derick Rethans wrote: > On Fri, 7 Jun 2013, Anatol Belski wrote: > > >> On Fri, June 7, 2013 12:45, Derick Rethans wrote: >> >>> On Thu, 6 Jun 2013, Pierre Joye wrote: >>> >>> >>> >>>> On Jun 6, 2013 6:03 PM, "Derick Rethans" <der...@php.net> wrote: >>>> >>>> >>>>> On Thu, 6 Jun 2013, Pierre Joye wrote: >>>>> >>>>> >>>>>> The fix for #53437 is around for some time now. It full fills >>>>>> the requirements described by Derick when we discussed the >>>>>> possible fixes. >>>>>> >>>>>> Unless there are strong objections in the next couple of days, >>>>>> I >>>>>> will ask Anatol to apply it on Monday. This is the last >>>>>> remaining crash in 5.3/4 (already applied in 5.5) and needs to >>>>>> be fixed asap. >>>>> >>>>> The last time I checked that it was using weird base64 encoding >>>>> on stuff and I am absolutely against that. Where is the new patch? >>>>> >>>> >>>> It is in 5.5 and no, it does not used that as stated in the >>>> previous mails. >>> >>> That didn't answer my question though. I asked where the new patch >>> was. >> >> That's the one where conversion int <> string for serialization was >> developed. It came into 5.5 with this patches (the originally proposed >> patch is still attached to that ticket) >> >> http://git.php.net/?p=php-src.git;a=commitdiff;h=0ee71557ffd285552659b6 >> aa37ea236e3bad493f > > ["days"]=> > - int(3) > + string(1) "3" > > > and > > - 'days' => 0, > + 'days' => '0', > > > I see this in all test cases - this is a BC break. Even though days is > an int64, I think this should be a (platform) int and not a string in case > it fits. No need to punish people on 64bit platforms. I'd even go as far > as arguing that special_amount should be treated like that too. The > deserializer needs to understand both types anyway. >
Just to be said that the idea from the original patch with base64 encoding was to export all the data without possible losses on 32 and 64 bit, besides fixing the crash. So I just continued that way. Exporting a 64 int as long can shrink the serialized value. This is anyway easy fixable by changing the macros. Also exporting even a shrinked value wouldn't cause a crash. Do I get it right we can backport it for 5.3/5.4 when it's fixed? Cheers Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
