Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
On Tue, Dec 27, 2011 at 9:01 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT
patrickalla...@php.netwrote:
2011/12/27 Ilia Alshanetsky i...@ilia.ws:
The change is inside 5.4 version which adjust breaks BC.
I don't follow you here Ilia.
As per https://wiki.php.net/rfc/releaseprocess:
* Backward compatibility must be respected with the same major
releases, for example from 5.2 to 5.6.
* Going from x.y.z to x.y+1.z, it is ok to break *binary*
compatibility but Backward compatibility must be kept.
However:
new DateTime(@{$_SERVER['REQUEST_TIME']});
works in 5.3 but not in 5.4.
AFAIK, creating a DateTime object based on the REQUEST_TIME is not an
exotic thing.
For sure, the fix is easy, but that is not the point, it *will*
actually break applications.
Did I miss something?
I think that he is referring to that we already break BC with 5.4
(removing magic_quotes, register_globals, break/continue
$var, allow_call_time_pass_reference, some deprecated session_ functions,
safe_mode, etc. for a complete list see
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/UPGRADING?view=markup
)
These are mostly removal of features, and most of these have been
deprecated for quite a while.
The REQUEST_TIME change however is a change of behaviour that has not been
warned about up front, which imo is a worse BC break then most of the rest.
And arguing for ignoring one bc break/bug/mistake because there are others
is.. well.. :)
However I tend to agree with you, that this BC break isn't really worth
it, we can see that there are common apps stumbling across this change, and
albeit the new behavior can be useful for many people, they wouldn't really
mind if we add this as a new variable imo.
Great, so I do think most people agree that this can, and should be fixed
before 5.4 by instead expose microtime on a separate variable called
REQUEST_TIME_FLOAT.
+1
Re: [PHP-DEV] Yet another fix for max_input_vars
On Fri, Jan 6, 2012 at 8:42 AM, Laruence larue...@php.net wrote: Hi: so here is the problem, the number index collision can be fixed by this idea (increase table size with a random delta). now we need add the random number into DJB hash, and I am not good at math, so Calling for help, and the random number will be stored in a process global variable like: PHPAPI int zend_hash_random_number. and the reason for use a process global variable are: 1. this would break the zend hash cache 2. no abi backward break ( zend_hash_func) 3. simplify ZTS protection.. A problem with a process global variable arises when the PHP process is kept alive between requests (e.g. fcgi). In that case the random value will stay the same between all requests and could be brute-forced. Not sure whether this is an issue in reality (e.g. what is the range of the random number?) Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] REQUEST_TIME change in PHP 5.4
2012/1/6 André Rømcke a...@ez.no
On Tue, Dec 27, 2011 at 9:01 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Tue, Dec 27, 2011 at 6:24 PM, Patrick ALLAERT patrickalla...@php.net
wrote:
2011/12/27 Ilia Alshanetsky i...@ilia.ws:
The change is inside 5.4 version which adjust breaks BC.
I don't follow you here Ilia.
As per https://wiki.php.net/rfc/releaseprocess:
* Backward compatibility must be respected with the same major
releases, for example from 5.2 to 5.6.
* Going from x.y.z to x.y+1.z, it is ok to break *binary*
compatibility but Backward compatibility must be kept.
However:
new DateTime(@{$_SERVER['REQUEST_TIME']});
works in 5.3 but not in 5.4.
AFAIK, creating a DateTime object based on the REQUEST_TIME is not an
exotic thing.
For sure, the fix is easy, but that is not the point, it *will*
actually break applications.
Did I miss something?
I think that he is referring to that we already break BC with 5.4 (removing
magic_quotes, register_globals, break/continue
$var, allow_call_time_pass_reference, some deprecated session_ functions,
safe_mode, etc. for a complete list
see http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/UPGRADING?view=markup )
These are mostly removal of features, and most of these have been deprecated
for quite a while.
The REQUEST_TIME change however is a change of behaviour that has not been
warned about up front, which imo is a worse BC break then most of the rest.
And arguing for ignoring one bc break/bug/mistake because there are others
is.. well.. :)
However I tend to agree with you, that this BC break isn't really worth it,
we can see that there are common apps stumbling across this change, and
albeit the new behavior can be useful for many people, they wouldn't really
mind if we add this as a new variable imo.
Great, so I do think most people agree that this can, and should be fixed
before 5.4 by instead expose microtime on a separate variable
called REQUEST_TIME_FLOAT.
+1
Fixed in master and PHP_5_4 as per discussed/suggested by introducing
$_SERVER['REQUEST_TIME_FLOAT'].
--
Patrick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Closures: Object extension
Hi, What is the status of this RFC: Closures: Object extension? https://wiki.php.net/rfc/closures/object-extension _md
[PHP-DEV] debugging PHP memory corruption
We've got a problem with PHP 5.3.8 and a third party (open source) library (WSo2 SOAP). At some point during the request to the PHP script, some structures seem to be getting corrupted causing PHP to crash. Depending on the code in the PHP script, it's either crashing during in a print_r/var_export or crashing when the PHP shuts down (the exact location of the crash moves around when we alter the code). We can reprod this on Win32 and Linux now. But how can we go about debugging where the corruption occurred? The address of the corrupted data is not known until the segfault/access violation occurs so we can't set a watch on it (as far as we can tell). Here's what we see in the debugger on Win32: Unhandled exception at 0x1008eb45 (php5ts.dll) in php-cgi.exe: Access violation reading location 0x4cac5400 php5ts.dll!_zval_ptr_dtor(_zval_struct * * zval_ptr=0x4cab5400) + 0x5 bytes php5ts.dll!zend_hash_destroy(_hashtable * ht=0x034cc0f0) + 0x27 bytes php5ts.dll!zend_objects_free_object_storage(_zend_object * object=0x03489fa0, void * * * tsrm_ls=0x003f42b0) + 0x2b bytes php5ts.dll!zend_objects_store_free_object_storage(_zend_objects_store * objects=0x003f685c, void * * * tsrm_ls=0x003f42b0) + 0x9c bytes php5ts.dll!shutdown_executor(void * * * tsrm_ls=0x003f42b0) + 0x2fe bytes php5ts.dll!zend_deactivate(void * * * tsrm_ls=0x003f42b0) + 0x91 bytes php5ts.dll!php_request_shutdown(void * dummy=0x) + 0x31f bytes php-cgi.exe!main(int argc=1, char * * argv=0x003f31d0) + 0xe89 bytes php-cgi.exe!__tmainCRTStartup() + 0x10f bytes Any tips welcomed. Andy. The information contained in this email is intended for the personal and confidential use of the addressee only. It may also be privileged information. If you are not the intended recipient then you are hereby notified that you have received this document in error and that any review, distribution or copying of this document is strictly prohibited. If you have received this communication in error, please notify Brendata immediately on: +44 (0)1268 466100, or email 'techni...@brendata.co.uk' Brendata (UK) Ltd Nevendon Hall, Nevendon Road, Basildon, Essex. SS13 1BX UK Registered Office as above. Registered in England No. 2764339 See our current vacancies at www.brendata.co.uk
Re: [PHP-DEV] debugging PHP memory corruption
On Fri, Jan 6, 2012 at 4:36 PM, Andrew Morum amo...@brendata.co.uk wrote: We've got a problem with PHP 5.3.8 and a third party (open source) library (WSo2 SOAP). hi Could you open a ticket on http://bugs.php.net and attach all the info that you have about the problem. If you could also attach a gdb backtrace following the steps on https://bugs.php.net/bugs-generating-backtrace.php that would be really useful. Thanks for your report! -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] PHP 5.4RC4 does not compile
Hi, I may be doing this wrong, but on a fresh Debian 6.03 install on a VMWare VM (VMWare tools installed, build-essential installed), the php5.4 rc4 tarball from snaps.php.net (php5.4-201201041830.tar.gz) does not compile. Here's what I did: tar xvzf php5.4-201201041830.tar.gz cd php5.4-201201041830 ./configure make And here's what it says: /bin/bash /home/steven/php5.4-201201041830/libtool --silent --preserve-dup-deps --mode=compile cc -IZend/ -I/home/steven/php5.4-201201041830/Zend/ -DPHP_ATOM_INC -I/home/steven/php5.4-201201041830/include -I/home/steven/php5.4-201201041830/main -I/home/steven/php5.4-201201041830 -I/home/steven/php5.4-201201041830/ext/date/lib -I/home/steven/php5.4-201201041830/ext/ereg/regex -I/usr/include/libxml2 -I/home/steven/php5.4-201201041830/ext/sqlite3/libsqlite -I/home/steven/php5.4-201201041830/TSRM -I/home/steven/php5.4-201201041830/Zend-I/usr/include -g -O2 -fvisibility=hidden -DZEND_SIGNALS -c /home/steven/php5.4-201201041830/Zend/zend_ini_parser.c -o Zend/zend_ini_parser.lo cc: /home/steven/php5.4-201201041830/Zend/zend_ini_parser.c: No such file or directory cc: no input files make: *** [Zend/zend_ini_parser.lo] Error 1 I'll be happy to provide any information you may need. Best regards, keep up the good work, Steven -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fw: [PHP] Implicit FTPS - New Feature Request
I am interested in contacting the author(s) of the ftp_ssl_connect function to discuss additions/enhancements to support implicit FTPS. I do have a person's name to contact (see below), but I thought it best to try a message here first. Thank you. Todd - Forwarded by Todd Nelson/FACSTAFF/UNO/UNEBR on 01/06/2012 10:56 AM - From: Matijn Woudt To: Todd Nelson tnel...@mail.unomaha.edu Cc: php-gene...@lists.php.net Date: 01/05/2012 12:16 PM Subject:Re: [PHP] Implicit FTPS On Thu, Jan 5, 2012 at 4:01 PM, Todd Nelson tnel...@mail.unomaha.edu wrote: My apologies if I'm in the wrong place, but I'm looking to discuss having PHP support implicit FTPS (currently only supports explicit.) I'd like to find the author(s) of the 'ftp_ssl_connect' function to discuss if this has already been considered and offer assistance if desired. Thank you. Todd Nelson Hi Todd, There's a special mailing list for PHP development (php-internals), that's probably a better to ask. `svn blame` on php_ftp.c shows that Stefan Esser (ses...@php.net) has written almost all lines of ftp_ssl_connect, so he's probably the author. Matijn
Re: [PHP-DEV] Closures: Object extension
It's been merged in 5.4 branch. http://svn.php.net/viewvc?view=revisionrevision=316300http://svn.php.net/viewvc?view=revisionrevision=316300 is the rev I think. Stas should have more info about that :) Cheers Julien.Pauli On Fri, Jan 6, 2012 at 3:47 PM, Marcello Duarte marcello.dua...@gmail.comwrote: Hi, What is the status of this RFC: Closures: Object extension? https://wiki.php.net/rfc/closures/object-extension _md
Re: [PHP-DEV] PHP 5.4RC4 does not compile
I'm using Ubuntu 11.10 (i686) and same problem in zend_ini_parser.c. As far I remember, RC3 worked fine here. On Fri, Jan 6, 2012 at 3:06 PM, Steven VAN POECK svanpo...@gmail.com wrote: Hi, I may be doing this wrong, but on a fresh Debian 6.03 install on a VMWare VM (VMWare tools installed, build-essential installed), the php5.4 rc4 tarball from snaps.php.net (php5.4-201201041830.tar.gz) does not compile. Here's what I did: tar xvzf php5.4-201201041830.tar.gz cd php5.4-201201041830 ./configure make And here's what it says: /bin/bash /home/steven/php5.4-201201041830/libtool --silent --preserve-dup-deps --mode=compile cc -IZend/ -I/home/steven/php5.4-201201041830/Zend/ -DPHP_ATOM_INC -I/home/steven/php5.4-201201041830/include -I/home/steven/php5.4-201201041830/main -I/home/steven/php5.4-201201041830 -I/home/steven/php5.4-201201041830/ext/date/lib -I/home/steven/php5.4-201201041830/ext/ereg/regex -I/usr/include/libxml2 -I/home/steven/php5.4-201201041830/ext/sqlite3/libsqlite -I/home/steven/php5.4-201201041830/TSRM -I/home/steven/php5.4-201201041830/Zend -I/usr/include -g -O2 -fvisibility=hidden -DZEND_SIGNALS -c /home/steven/php5.4-201201041830/Zend/zend_ini_parser.c -o Zend/zend_ini_parser.lo cc: /home/steven/php5.4-201201041830/Zend/zend_ini_parser.c: No such file or directory cc: no input files make: *** [Zend/zend_ini_parser.lo] Error 1 I'll be happy to provide any information you may need. Best regards, keep up the good work, Steven -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Atenciosamente, Rafael Kassner -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.4RC4 does not compile
On 01/06/2012 09:06 PM, Steven VAN POECK wrote: I may be doing this wrong, but on a fresh Debian 6.03 install on a VMWare VM (VMWare tools installed, build-essential installed), the php5.4 rc4 tarball from snaps.php.net (php5.4-201201041830.tar.gz) does not compile. Can you still reproduce it with RC5? I can't see any problems here both with and without bison installed (which is used to generate this file from zend_ini_parser.y). -- Wbr, Antony Dovgal --- http://pinba.org - realtime profiling for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4.0RC5 released
Happy new year internals, We start off the new year with the release of the 5th release candidate of PHP 5.4.0 You can find the release here: http://downloads.php.net/stas The Windows team provides windows binaries for the release. As always you find them at: http://windows.php.net/qa/ Please ensure that the release is solid and all things behave as expected! Test the release candidate against your code base and report any problems you encounter or successful tests you've run. The 6th release candidate will be released on January 19. regards, Stas and David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
