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

2013-03-13 Thread Anatol Belski
On Mon, 2013-03-11 at 11:42 +, Derick Rethans wrote: 
 Please, no top posting!
 
 On Mon, 11 Mar 2013, Anatol Belski wrote:
  On Sun, March 10, 2013 23:11, Derick Rethans wrote:
   On Sat, 9 Mar 2013, Anatol Belski wrote:
  
   On Sat, 2013-03-09 at 21:57 +0100, Gustavo Lopes wrote:
  
   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)?
  
   Why do you need libgmp for that‽
 
  libgmp was just the first shot as it has functions to convert from 
  arbitrary binary data to string and vice versa, mpz_import and 
  mpz_export. That's what should work fine across platforms. Looking at 
  the type definitions here 
  http://lxr.php.net/xref/PHP_5_5/ext/date/lib/timelib_structs.h#70 i 
  wouldn't exclude possible platform issues. Implementing that manually 
  is a tricky job, could be done probably with more homework :)
  
  What is the way you had in the mind to achieve the string-integer 
  conversions?
 
 atoll() (or atoq()).

Please take a look at the reworked patch in #53437

https://bugs.php.net/patch-display.php?bug_id=53437patch=date_patch_var3.patchrevision=latest

Serializing 64 bit integers as strings.

Regards

Anatol

 
 cheers,
 Derick
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php



-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



FW: [PHP-DEV] DateTime-modify('tomorrow') Bug in PHP 5.3 on Linux

2013-03-13 Thread Christian Stoller
Hi Derick.

 The 5.3.14 result is correct. It was apparently a bug in earlier 5.3 
 versions.

 cheers,
 Derick

Thanks for this hint. So I guess that Debian has not ported the bugfix. Do you 
know the Git Revision of the patch? I would like to inform the PHP maintainers 
of Debian so that they can easily integrate the fix.

Thanks for help!


[PHP-DEV] idea: add wrapper support to mysqli_connect

2013-03-13 Thread Thomas Anderson
Instead of passing localhost to mysqli_connect as the $host parameter
I think it'd be useful if you could pass something like
ssh2.tunnel://user:p...@example.com:22/192.168.0.1:14 to it as well.

The main advantage I see of doing that is that you could tunnel
through SSH2, through SOCKS, through HTTP CONNECT, etc, a lot more
easily than you currently can. Like you could have an SSH connection
re-created every time a PHP script is called and a tunnel dynamically
made instead of having a persistent tunnel created with autossh or
whatever.

And even if SSH2 / SOCKS / CONNECT don't exist as built-in wrappers
custom stream wrappers could be made. This would additionally make it
easy for people to examine the underpinnings of MySQL. Instead of
intercepting the packets the MySQL client sends out and placing them
into an SSH tunnel or whatever one could just dump them to a log file
to better understand how MySQL clients work internally.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] idea: add wrapper support to mysqli_connect

2013-03-13 Thread Rasmus Lerdorf
On 03/13/2013 12:08 PM, Thomas Anderson wrote:
 Instead of passing localhost to mysqli_connect as the $host parameter
 I think it'd be useful if you could pass something like
 ssh2.tunnel://user:p...@example.com:22/192.168.0.1:14 to it as well.
 
 The main advantage I see of doing that is that you could tunnel
 through SSH2, through SOCKS, through HTTP CONNECT, etc, a lot more
 easily than you currently can. Like you could have an SSH connection
 re-created every time a PHP script is called and a tunnel dynamically
 made instead of having a persistent tunnel created with autossh or
 whatever.
 
 And even if SSH2 / SOCKS / CONNECT don't exist as built-in wrappers
 custom stream wrappers could be made. This would additionally make it
 easy for people to examine the underpinnings of MySQL. Instead of
 intercepting the packets the MySQL client sends out and placing them
 into an SSH tunnel or whatever one could just dump them to a log file
 to better understand how MySQL clients work internally.

Instead of adding all that gear to PHP itself, wouldn't it make more
sense to just use something like autossh to maintain your ssh tunnel and
have PHP connect to your tunnel endpoint? mysqli_connect() in PHP is
just a thin wrapper on top of the underlying library.

And your debugging use-case is also handled nicely by external tools
that listen on a unix-domain socket, for example.

-Rasmus


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP-DEV] idea: add wrapper support to mysqli_connect

2013-03-13 Thread Thomas Anderson
On Wed, Mar 13, 2013 at 3:37 PM, Rasmus Lerdorf ras...@lerdorf.com wrote:
 On 03/13/2013 12:08 PM, Thomas Anderson wrote:
 Instead of passing localhost to mysqli_connect as the $host parameter
 I think it'd be useful if you could pass something like
 ssh2.tunnel://user:p...@example.com:22/192.168.0.1:14 to it as well.

 The main advantage I see of doing that is that you could tunnel
 through SSH2, through SOCKS, through HTTP CONNECT, etc, a lot more
 easily than you currently can. Like you could have an SSH connection
 re-created every time a PHP script is called and a tunnel dynamically
 made instead of having a persistent tunnel created with autossh or
 whatever.

 And even if SSH2 / SOCKS / CONNECT don't exist as built-in wrappers
 custom stream wrappers could be made. This would additionally make it
 easy for people to examine the underpinnings of MySQL. Instead of
 intercepting the packets the MySQL client sends out and placing them
 into an SSH tunnel or whatever one could just dump them to a log file
 to better understand how MySQL clients work internally.

 Instead of adding all that gear to PHP itself, wouldn't it make more
 sense to just use something like autossh to maintain your ssh tunnel and
 have PHP connect to your tunnel endpoint? mysqli_connect() in PHP is
 just a thin wrapper on top of the underlying library.

Oh - I didn't know that. I thought (hoped) it might have been like a
two second code change lol.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php