Re: [PHP-DEV] Fix for bug #63437
On Tue, 5 Mar 2013, Anatol Belski wrote: I've reworked the patch from http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff (mentioned by tony2001) for bug #63437, that seems to fix the issue. That patch was ported back to 5.3 and adapted to the current 5.4+. Both variants are posted to the ticket. Serializing this as a base64 encoded variant of some binary data is not a good thing. If you want to serialize, it needs to output the same thigns that allow users to create the period or interval. I also don't think this would work for Big Endian vs Little Endian either. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Optimizer+ bugreps
On Fri, 8 Mar 2013, Hannes Magnusson wrote: On Fri, Mar 8, 2013 at 12:56 PM, Christopher Jones christopher.jo...@oracle.com wrote: Felipe added ZO+ to the bugs.php.net Package affected drop-down today. Hmmh.. That shouldn't be there as the current official issue tracker for it is on github, and is linked from the pecl page.. Only since a day or two - there is no reason why we can't have it in our normal bug tracker as the extension is going to be part of that very soon anyway. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix for bug #63437
On Sat, 09 Mar 2013 21:36:41 +0100, Derick Rethans der...@php.net wrote: On Tue, 5 Mar 2013, Anatol Belski wrote: I've reworked the patch from http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff (mentioned by tony2001) for bug #63437, that seems to fix the issue. That patch was ported back to 5.3 and adapted to the current 5.4+. Both variants are posted to the ticket. Serializing this as a base64 encoded variant of some binary data is not a good thing. If you want to serialize, it needs to output the same thigns that allow users to create the period or interval. I would agree in principle, but, as I explained before, there is a problem. The DatePeriod class has 64-bit integers in its internal structure. The PHP integer type cannot (in general) represent that data. So the general method of getting the object data via get_properties and serializing (and then using __set_state to convert the array back) does not work unless you represent those 64-bit integers with some non-integer type and do the conversions. I also don't think this would work for Big Endian vs Little Endian either. It does; the integers are converted to network order before being stored, so you can share the serialized data between machines with different endianness. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Allow non-scalar keys in foreach
On Wed, Mar 6, 2013 at 6:28 PM, Dmitry Stogov dmi...@zend.com wrote: I wonder what would be a good way to avoid allocating a temporary zval for the key and freeing it again. Do you think it would be okay to pass EX_T((opline+1)-result.var).tmp_var into -get_current_key() so the value can be written directly into it without doing extra allocs/frees? I'm not sure it'll work. TMP_VARs don't initialize refcount, they can't be referenced or marked as a possible root of garbage. I took only a very quick look over the patch and didn't understand all the details, but probably it must be possible to copy iterator key into TMP_VAR and call copy_ctor(). Please, let me review the patch when it's ready (I won't be available on March 8 and weekend). Thanks. Dmitry. Here is the new patch: https://github.com/nikic/php-src/commit/a1bfc8105713eeb4e66e852b81884b567ad56020 It passes in the tmp_var in as a zval*, which can then be set using the ZVAL_* macros (basically the same way as it's done with return_value). This way we don't need any further zval allocs and frees. It also turned out that doing it this way is more convenient to use in the respective key handlers. Nikita
Re: [PHP-DEV] Fix for bug #63437
Hi, On Sat, 2013-03-09 at 21:57 +0100, Gustavo Lopes wrote: On Sat, 09 Mar 2013 21:36:41 +0100, Derick Rethans der...@php.net wrote: On Tue, 5 Mar 2013, Anatol Belski wrote: I've reworked the patch from http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff (mentioned by tony2001) for bug #63437, that seems to fix the issue. That patch was ported back to 5.3 and adapted to the current 5.4+. Both variants are posted to the ticket. Serializing this as a base64 encoded variant of some binary data is not a good thing. If you want to serialize, it needs to output the same thigns that allow users to create the period or interval. I would agree in principle, but, as I explained before, there is a problem. The DatePeriod class has 64-bit integers in its internal structure. The PHP integer type cannot (in general) represent that data. So the general method of getting the object data via get_properties and serializing (and then using __set_state to convert the array back) does not work unless you represent those 64-bit integers with some non-integer type and do the conversions. So base64 seems to be only the doubtful point. Thriving to fix that, what if we could bring it in dependency of libgmp to serialize and read as strings (and maybe disable serialization otherwise)? I also don't think this would work for Big Endian vs Little Endian either. It does; the integers are converted to network order before being stored, so you can share the serialized data between machines with different endianness. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix for bug #63437
On Sat, 9 Mar 2013, Gustavo Lopes wrote: On Sat, 09 Mar 2013 21:36:41 +0100, Derick Rethans der...@php.net wrote: On Tue, 5 Mar 2013, Anatol Belski wrote: I've reworked the patch from http://nebm.ist.utl.pt/~glopes/misc/date_period_interval_ser.diff (mentioned by tony2001) for bug #63437, that seems to fix the issue. That patch was ported back to 5.3 and adapted to the current 5.4+. Both variants are posted to the ticket. Serializing this as a base64 encoded variant of some binary data is not a good thing. If you want to serialize, it needs to output the same thigns that allow users to create the period or interval. I would agree in principle, but, as I explained before, there is a problem. The DatePeriod class has 64-bit integers in its internal structure. The PHP integer type cannot (in general) represent that data. So the general method of getting the object data via get_properties and serializing (and then using __set_state to convert the array back) does not work unless you represent those 64-bit integers with some non-integer type and do the conversions. Then store them as strings or another format that makes it possible to get a 64bit timestamp back. Of course, I don't think it makes too much sense to serialize a Period as it's more of a transient iterator wrapper. For an interval, you'd want to serialise the original input vectors as well... not an easy task (unless you store the original). cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
