Re: [PHP-DEV] Fix for bug #63437

2013-03-09 Thread Derick Rethans
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

2013-03-09 Thread Derick Rethans
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

2013-03-09 Thread Gustavo Lopes

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

2013-03-09 Thread Nikita Popov
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

2013-03-09 Thread Anatol Belski
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

2013-03-09 Thread Derick Rethans
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