Re: [PHP-DEV] 64bit Windows builds
2012/1/19 Ángel González keis...@gmail.com: Actually, why couldn't mingw be supported one day? (supposing someone did the work to change half the PHP_WIN defines to PHP_MSVC) Too painful, somehow buggy (while it is way better lately) but the main reason is total lack of binary compatibility with supported VC versions. And we do not have the resources to provide support for more than one compiler version at a time. Such binaries wouldn't be compatible with IIS, but mingw seems preferible to the legacy VC6 for use with the oficial Apache binaries. There is no such thing like official apache binaries, they provide some as conveniences. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences
Hi,
On Fri, 2011-11-18 at 16:06 -0500, Daniel Convissor wrote:
The length property is what's tripping up my unit tests. I'm building
PHP 5.4 from svn for both tests. The only difference between them is
the with-mysqli declaration. Here is a table summarizing the situation:
type libmysql mysqlnd
---
TEXT 65535 196605
CHAR(2) 26
Is this intended behavior?
Your server seems to be configured for UTF-8 by default. In my tests the
behavior for both libraries (myslqnd libmsql) is the same if you mind
the character set (use SET NAMES etc.)
The documentation tells
unsigned long length
The width of the field. This corresponds to the display length,
in bytes.
The server determines the length value before it generates the
result set, so this is the minimum length required for a data
type capable of holding the largest possible value from the
result column, without knowing in advance the actual values that
will be produced by the query for the result set.
http://dev.mysql.com/doc/refman/5.5/en/c-api-data-structures.html
So it is working in bytes and has to hold all possible values.
I'll mark #60333 as bogus (expected behavior) once master works for
login ...
johannes
--
Johannes Schlüter, MySQL Engineering Connectors and Client Connectivity
ORACLE Deutschland B.V. Co. KG, Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603 Geschäftsführer: Jürgen Kunz
Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences
Am 19.01.2012 13:50, schrieb Johannes Schlüter:
On Fri, 2011-11-18 at 16:06 -0500, Daniel Convissor wrote:
The length property is what's tripping up my unit tests. I'm building
PHP 5.4 from svn for both tests. The only difference between them is
the with-mysqli declaration. Here is a table summarizing the situation:
type libmysql mysqlnd
---
TEXT 65535 196605
CHAR(2) 26
Is this intended behavior?
Your server seems to be configured for UTF-8 by default. In my tests the
behavior for both libraries (myslqnd libmsql) is the same if you mind
the character set (use SET NAMES etc.)
ACK, likely a bogus report.
MySQLnd always assumes the server default charset. This charset is sent
during connection hand-shake/authentication, which mysqlnd will use.
Libmysql uses the default charset set in the my.cnf or by an explicit
call to mysqli_options() prior to calling mysqli_real_connect(), but
after mysqli_init()., http://www.php.net/manual/en/mysqli.construct.php
Ulf
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] merging test improvement to PHP_5_4
Hi, I fixed https://bugs.php.net/bug.php?id=52078, I would like to add the test improvement to the 5.4 branch also, is it ok to commit, or should I wait the release with it? see http://svn.php.net/viewvc?view=revisionrevision=322460 -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] merging test improvement to PHP_5_4
I guess 5.4 branch is under code freeze. http://marc.info/?l=php-internalsm=132617955007428w=2 On Thu, Jan 19, 2012 at 5:07 PM, Ferenc Kovacs tyr...@gmail.com wrote: Hi, I fixed https://bugs.php.net/bug.php?id=52078, I would like to add the test improvement to the 5.4 branch also, is it ok to commit, or should I wait the release with it? see http://svn.php.net/viewvc?view=revisionrevision=322460 -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Atenciosamente, Rafael Kassner
Re: [PHP-DEV] merging test improvement to PHP_5_4
And this is why I asked it. The following may be considered for inclusion: - Unit tests test fixes .. Please still ask RMs for approval prior to committing even if your patch falls into these categories. On Thu, Jan 19, 2012 at 8:12 PM, Rafael Kassner kass...@gmail.com wrote: I guess 5.4 branch is under code freeze. http://marc.info/?l=php-internalsm=132617955007428w=2 On Thu, Jan 19, 2012 at 5:07 PM, Ferenc Kovacs tyr...@gmail.com wrote: Hi, I fixed https://bugs.php.net/bug.php?id=52078, I would like to add the test improvement to the 5.4 branch also, is it ok to commit, or should I wait the release with it? see http://svn.php.net/viewvc?view=revisionrevision=322460 -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- Atenciosamente, Rafael Kassner -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences
Gentlemen: On Thu, Jan 19, 2012 at 02:09:12PM +0100, Ulf Wendel wrote: Am 19.01.2012 13:50, schrieb Johannes Schlüter: Your server seems to be configured for UTF-8 by default. In my tests the behavior for both libraries (myslqnd libmsql) is the same if you mind the character set (use SET NAMES etc.) Yes, my server is set to UTF-8 in my.cnf: character-set-server = utf8 MySQLnd always assumes the server default charset. This charset is sent during connection hand-shake/authentication, which mysqlnd will use. Libmysql uses the default charset set in the my.cnf or by an explicit call to mysqli_options() prior to calling mysqli_real_connect(), but after mysqli_init()., http://www.php.net/manual/en/mysqli.construct.php From the documentation exceprt, above, the test code in https://bugs.php.net/bug.php?id=60333 should be using the server's default character set under both mysqlnd and libmysql. So shouldn't they both come back with the same answer? Or am I misunderstanding something? Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] merging test improvement to PHP_5_4
Hi! I fixed https://bugs.php.net/bug.php?id=52078, I would like to add the test improvement to the 5.4 branch also, is it ok to commit, or should I wait the release with it? Please hold it, we are announcing RC6 soon and plan to release in 2 weeks, in this period I'd like to keep the SVN as stable as possible. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences
Am 19.01.2012 20:27, schrieb Daniel Convissor: Gentlemen: On Thu, Jan 19, 2012 at 02:09:12PM +0100, Ulf Wendel wrote: Am 19.01.2012 13:50, schrieb Johannes Schlüter: Your server seems to be configured for UTF-8 by default. In my tests the behavior for both libraries (myslqnd libmsql) is the same if you mind the character set (use SET NAMES etc.) Yes, my server is set to UTF-8 in my.cnf: character-set-server = utf8 MySQLnd always assumes the server default charset. This charset is sent during connection hand-shake/authentication, which mysqlnd will use. Libmysql uses the default charset set in the my.cnf or by an explicit call to mysqli_options() prior to calling mysqli_real_connect(), but after mysqli_init()., http://www.php.net/manual/en/mysqli.construct.php From the documentation exceprt, above, the test code in https://bugs.php.net/bug.php?id=60333 should be using the server's default character set under both mysqlnd and libmysql. So shouldn't they both come back with the same answer? Or am I misunderstanding something? mysqlnd simply does not read MySQL server config. It defaults to actual connection of the server. Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mysqli_fetch_field() mysqlnd libmysql differences
Hi: On Thu, Jan 19, 2012 at 02:27:05PM -0500, Daniel Convissor wrote: On Thu, Jan 19, 2012 at 02:09:12PM +0100, Ulf Wendel wrote: Am 19.01.2012 13:50, schrieb Johannes Schlüter: Your server seems to be configured for UTF-8 by default. In my tests the behavior for both libraries (myslqnd libmsql) is the same if you mind the character set (use SET NAMES etc.) Yes, my server is set to UTF-8 in my.cnf: character-set-server = utf8 MySQLnd always assumes the server default charset. This charset is sent during connection hand-shake/authentication, which mysqlnd will use. Libmysql uses the default charset set in the my.cnf or by an explicit call to mysqli_options() prior to calling mysqli_real_connect(), but after mysqli_init()., http://www.php.net/manual/en/mysqli.construct.php From the documentation exceprt, above, the test code in https://bugs.php.net/bug.php?id=60333 should be using the server's default character set under both mysqlnd and libmysql. So shouldn't they both come back with the same answer? Or am I misunderstanding something? Hmm. I added a call to $db-character_set_name() in the test script. Under mysqlnd it returns utf8 while under libmysql it returns latin1. So that explains the difference. But that leads me to the next head scratcher: why is libmysql not using the default charset set in the my.cnf? Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] merging test improvement to PHP_5_4
On Thu, Jan 19, 2012 at 8:30 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! I fixed https://bugs.php.net/bug.php?**id=52078https://bugs.php.net/bug.php?id=52078, I would like to add the test improvement to the 5.4 branch also, is it ok to commit, or should I wait the release with it? Please hold it, we are announcing RC6 soon and plan to release in 2 weeks, in this period I'd like to keep the SVN as stable as possible. ok -- Ferenc Kovács @Tyr43l - http://tyrael.hu
[PHP-DEV] [Patch] Implement PBKDF2 in the Hash package
Hi all, I've implemented a patch (attached to the bug, but in a gist as well here https://gist.github.com/1641725 ) that implements a hash_pbkdf2() function. The patch also slightly refactors hash_hmac() to split out a little bit of common functionality (since pbkdf2 relies upon hmac). https://bugs.php.net/bug.php?id=60813 I've targeted the patch towards trunk for now, but I'd like to see if it could get into 5.3 and 5.4 as well (in a point release). Let me know your thoughts, Thanks, Anthony -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 5.4.0 rc6 and release
Hi! We'll be announcing RC6 very soon, and we're planning the final release for February 2nd. The two weeks in between are meant for testing and finding out any critical issues that could prevent us from releasing 5.4.0. If we have none of these, we will proceed with the release. To ensure this release would not have any surprises, I am asking again to hold your commits to 5.4 branch unless you have a critical bug fix AND it is approved by the RMs (myself and David). Thanks for your help! -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.0 rc6 and release
Hi, great to see progress! I have some small questions, please don't feel offended, I just want to know and understand: - According to this website there are still 94 test failures in 5.4 . Can you confirm all of them are minor problems? http://gcov.php.net/viewer.php?version=PHP_5_4 - There was this problem with 5.3.7 and the crypt() bug. Has there been some improvement in the process of handling test failures? For example mark expected failures as expected failures, and fix the tests or the code? Or are the failing tests stable since month and all of them are minor problems? - There have been 319 unique failed tests in RC5, reported by user tests. Is someone looking into them and trying to classify and/or fix them? http://qa.php.net/reports/ All in all the number of test failures still feels very high, I would be interested in your opinion. Is this normal for big projects like this? Again, please take these questions as normal questions, I don't want to attack anybody, I'm just interested in the process and relatively new to internal PHP development. Thanks for your work on PHP! Michael Am 19.01.2012 23:55, schrieb Stas Malyshev: Hi! We'll be announcing RC6 very soon, and we're planning the final release for February 2nd. The two weeks in between are meant for testing and finding out any critical issues that could prevent us from releasing 5.4.0. If we have none of these, we will proceed with the release. To ensure this release would not have any surprises, I am asking again to hold your commits to 5.4 branch unless you have a critical bug fix AND it is approved by the RMs (myself and David). Thanks for your help! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP 5.4.0RC6 released
Hi internals After five release candidates we are reaching the end of the RC phase. If we do not encounter critical bugs in the next two weeks, then this 6th RC will be tagged as 5.4.0 final. You can download the packages from: 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. Please focus on testing traits. An important bug was fixed in the last two weeks and we need traits tested The next release will hopefully be the final. We plan to release it on February 2. NOTE: Do not commit anything without asking Stas or me. The packages will be build on Jan 31, so Jan 30 will be the last day for commits to 5.4.0. regards, Stas and David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.0 rc6 and release
Hi! - According to this website there are still 94 test failures in 5.4 . Can you confirm all of them are minor problems? http://gcov.php.net/viewer.php?version=PHP_5_4 Most of them appear so, I'll go through them again to be sure and encourage others to do so too and raise red flags if somebody sees something bad there. Unfortunately, some tests are environment-dependent or otherwise have subtle dependencies or structure that make them work on one system and fail on another not because of the bug in PHP but because of the test itself. So, I have 0 fails on my Linux build but 6 fails on my Mac build. Other times some systems may not support some capability, use old version of the library, etc. and the test may not account for that. I do not think it is practical to postpone release until we solve all of such problems, since this being volunteer-driven open-source project this means not having any release schedule at all. I prefer having the schedule even if that means we'd have to release with some known deficiencies. - There was this problem with 5.3.7 and the crypt() bug. Has there been some improvement in the process of handling test failures? For example mark expected failures as expected failures, and fix the tests or the code? Or are the failing tests stable since month and all of them are minor problems? Yes, there was work done on these. Most of those were fixed, but few still remain, especially across various environments (i.e. test may be fine on some but not others). I of course am all for fixing that further and welcome any help on that. - There have been 319 unique failed tests in RC5, reported by user tests. Is someone looking into them and trying to classify and/or fix them? http://qa.php.net/reports/ Non-reproducible failures usually mean the problem is with the test itself, or with the difference of expectations in the test and local environment, not with PHP. It may still be PHP problem, of course, so the person running the test should check it out and submit a bug if appropriate and if it's bad enough, also send a message to this list. All in all the number of test failures still feels very high, I would be interested in your opinion. Is this normal for big projects like this? I do think it should be reduced, however if the choice is between waiting forever and have release with some bugs, I think it is practical to choose the latter. Of course, if we discover a major problem that makes PHP unusable or seriously impacts many PHP users, it will be dealt with immediately, and had been so in the past, but otherwise we have to work within the realities of a big project with limited resources and realize that while we strive for 0 bugs in every release, it may never be possible. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.0 rc6 and release
Excerpts from Stas Malyshev's message of Thu Jan 19 16:08:28 -0800 2012: Hi! - According to this website there are still 94 test failures in 5.4 . Can you confirm all of them are minor problems? http://gcov.php.net/viewer.php?version=PHP_5_4 Most of them appear so, I'll go through them again to be sure and encourage others to do so too and raise red flags if somebody sees something bad there. Unfortunately, some tests are environment-dependent or otherwise have subtle dependencies or structure that make them work on one system and fail on another not because of the bug in PHP but because of the test itself. So, I have 0 fails on my Linux build but 6 fails on my Mac build. Other times some systems may not support some capability, use old version of the library, etc. and the test may not account for that. These tests should be skipped or marked as XFAIL on platforms they are known to fail on. Better to have no test than one that cannot be relied upon. All supported platforms should pass with 0 fails. These intentional skips should have open bugs that are documented in the test code so that a developer can find out why this test was disabled when trying to make a change covered by the test. I do not think it is practical to postpone release until we solve all of such problems, since this being volunteer-driven open-source project this means not having any release schedule at all. I prefer having the schedule even if that means we'd have to release with some known deficiencies. Its pretty bad actually. For all of PHP's success, this is something that continues to baffle me, and many others I have talked to who are charged with measuring quality and with patching systems in a timely manner. How better to document unreliable tests than to skip them with something like SKIPPED - known to fail on Mac. Its precisely this unreliability that forced me to take a conservative approach for Ubuntu 12.04 and recommend to the community that we ship 5.3.9 instead of 5.4.0. I would much rather have the new stuff in, but even if all the tests pass on the machine we run the test suite on, how can we be sure they won't fail in another time zone, or in some other strange configuration? - There was this problem with 5.3.7 and the crypt() bug. Has there been some improvement in the process of handling test failures? For example mark expected failures as expected failures, and fix the tests or the code? Or are the failing tests stable since month and all of them are minor problems? Yes, there was work done on these. Most of those were fixed, but few still remain, especially across various environments (i.e. test may be fine on some but not others). I of course am all for fixing that further and welcome any help on that. - There have been 319 unique failed tests in RC5, reported by user tests. Is someone looking into them and trying to classify and/or fix them? http://qa.php.net/reports/ Non-reproducible failures usually mean the problem is with the test itself, or with the difference of expectations in the test and local environment, not with PHP. It may still be PHP problem, of course, so the person running the test should check it out and submit a bug if appropriate and if it's bad enough, also send a message to this list. All in all the number of test failures still feels very high, I would be interested in your opinion. Is this normal for big projects like this? I do think it should be reduced, however if the choice is between waiting forever and have release with some bugs, I think it is practical to choose the latter. Of course, if we discover a major problem that makes PHP unusable or seriously impacts many PHP users, it will be dealt with immediately, and had been so in the past, but otherwise we have to work within the realities of a big project with limited resources and realize that while we strive for 0 bugs in every release, it may never be possible. All software will have bugs. The test suite, however, should reflect the bits of code that you know work reliably... not the bits of code you know work most of the time. The fact that its all being running regularly is a fantastic improvement. I'd like to see a commitment to getting 100% pass/xfail/skip for every release/tested environment in future releases though. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4.0 rc6 and release
Hi! These tests should be skipped or marked as XFAIL on platforms they are known to fail on. Better to have no test than one that cannot be relied upon. All supported platforms should pass with 0 fails. These intentional Of course they should, and you (or anybody else) are welcome to make the patches that make them so :) I promise they'll be in 5.4.1. Its precisely this unreliability that forced me to take a conservative approach for Ubuntu 12.04 and recommend to the community that we ship 5.3.9 instead of 5.4.0. I would much rather have the new stuff in, but 5.4.0 is better, not worse, than 5.3.9 in this regard - especially because of the work that was done in 5.4 branch to fix or improve tests that were failing and improve test coverage. I would advise to give your users a choice once 5.4.0 is released and support both packages. On my Linux environment, I have now 0 fails (though I don't run all modules so some of non-default ones may be missing). even if all the tests pass on the machine we run the test suite on, how can we be sure they won't fail in another time zone, or in some other strange configuration? Well, you never can be *sure* - tests can test only things they know about, unless somebody invents a way to make unit test test every possible combination of environments at once. So far I never heard about such tests. The fact that its all being running regularly is a fantastic improvement. I'd like to see a commitment to getting 100% pass/xfail/skip for every release/tested environment in future releases though. I'd like that too. I hope more people will step up and help to make this a reality. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Code freeze for 5.4
Hi Stats, I would like to commit session adaption patch to 5.4, since it does not change current session module behavior by default and affected application can be protected by changing php.ini setting. As you already know, it requires structure changes and it would be binary incompatible if add it later. If there is no objections, I'll commit it to both trunk and 5.4. For PHP 5.3, we can modify patch so that it does not require module structure changes, but I don't have spare time to do that now. PHP 5.3 users may user land (user script base) solution still. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/1/8 Stas Malyshev smalys...@sugarcrm.com: Hi! As we are nearing the release of 5.4.0, I'd like to ask everybody not to commit anything to 5.4 branch without the approval of one of the RMs (myself or David) from now until release of 5.4.0. Unless something critical for 5.4.0 is found, we'd like RC6 (planned on Jan 19) to be the final RC and the code which we release. The following may be considered for inclusion: - Unit tests test fixes - Fixes for critical bugs - Security fixes - BC break fixes Please still ask RMs for approval prior to committing even if your patch falls into these categories. Commits to trunk are OK. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- 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
Re: [PHP-DEV] Code freeze for 5.4
Hi! I would like to commit session adaption patch to 5.4, since it does not change current session module behavior by default and affected application can be protected by changing php.ini setting. As you already know, it requires structure changes and it would be binary incompatible if add it later. I feel such a big patch would without doubt require another RC and thus delay release of 5.4.0 by at least 2 weeks. So unless this patch is perceived as required by the community I would advise to not commit it to 5.4 now. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Code freeze for 5.4
I added a patch to bug #60809. If it's ok I can commit it. Pierrick On 19 January 2012 20:55, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I would like to commit session adaption patch to 5.4, since it does not change current session module behavior by default and affected application can be protected by changing php.ini setting. As you already know, it requires structure changes and it would be binary incompatible if add it later. I feel such a big patch would without doubt require another RC and thus delay release of 5.4.0 by at least 2 weeks. So unless this patch is perceived as required by the community I would advise to not commit it to 5.4 now. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- 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
[PHP-DEV] Bug #60809
I just open a new thread just for this bug.
If one of the RM could please confirm that I can commit the patch to
the PHP5.4 branch.
Thanks
Pierrick
Index: NEWS
===
--- NEWS(revision 322482)
+++ NEWS(working copy)
@@ -7,6 +7,7 @@
- Core:
. Restoring $_SERVER['REQUEST_TIME'] as a long and introducing
$_SERVER['REQUEST_TIME_FLOAT'] to include microsecond precision. (Patrick)
+ . Fixed bug #60809 (Traits phpdoc double free) (Pierrick)
. Fixed bug #60768 (Output buffer not discarded) (Mike)
- Hash
Index: Zend/zend_compile.c
===
--- Zend/zend_compile.c (revision 322482)
+++ Zend/zend_compile.c (working copy)
@@ -4141,6 +4141,7 @@
zend_bool parent_prop_is_private = 0;
zend_bool not_compatible;
zval* prop_value;
+ char *doc_comment;
/* In the following steps the properties are inserted into the property
table
@@ -4236,9 +4237,15 @@
}
Z_ADDREF_P(prop_value);
+ if (property_info-doc_comment) {
+ doc_comment =
estrndup(property_info-doc_comment, property_info-doc_comment_len);
+ } else {
+ doc_comment = NULL;
+ }
+
zend_declare_property_ex(ce, prop_name,
prop_name_length,
prop_value, property_info-flags,
-
property_info-doc_comment, property_info-doc_comment_len TSRMLS_CC);
+
doc_comment, property_info-doc_comment_len TSRMLS_CC);
}
}
}
Index: Zend/tests/bug60809.phpt
===
--- Zend/tests/bug60809.phpt(revision 0)
+++ Zend/tests/bug60809.phpt(revision 0)
@@ -0,0 +1,18 @@
+--TEST--
+Bug #60809 (traits - phpdoc double free)
+--FILE--
+?php
+
+class Example {
+use ExampleTrait;
+}
+
+trait ExampleTrait {
+/**
+ *
+ */
+public $hello_world = 'hello World ^^';
+}
+echo 'DONE';
+--EXPECT--
+DONE
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Code freeze for 5.4
Hi Stats, Ok, I'll hold committing to 5.4, but commit it only to trunk. Any comments form anyone? for committing to trunk? Patch details and user land counter measure are in RFC. https://wiki.php.net/rfc/strict_sessions BTW, if we hold this patch, I think we should write patch that does not touch PS module structure for PHP 5.4, too. In this case, users cannot distinguish whether PS module is adoptive or not. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/1/20 Stas Malyshev smalys...@sugarcrm.com: Hi! I would like to commit session adaption patch to 5.4, since it does not change current session module behavior by default and affected application can be protected by changing php.ini setting. As you already know, it requires structure changes and it would be binary incompatible if add it later. I feel such a big patch would without doubt require another RC and thus delay release of 5.4.0 by at least 2 weeks. So unless this patch is perceived as required by the community I would advise to not commit it to 5.4 now. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] session_regenerate_id() not replacing Set-Cookie header
Hi Stats, Even if this bug is marked as bogus in bug DB, I think this bug needed to be fixed for 5.4. https://bugs.php.net/bug.php?id=38104 It seems this bug causes problem with IE that not keeping session correctly. From RFC 6250 - Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name. (See Section 5.2 for how user agents handle this case.) - http://datatracker.ietf.org/doc/rfc6265/?include_text=1 It seems IE conform this standard. According to svn log, it seems it was not fixed. Anyone working with this issue? or already fixed? I'm just curious. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net 2012/1/9 Ferenc Kovacs tyr...@gmail.com: On Wed, Nov 16, 2011 at 12:30 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Wed, Nov 16, 2011 at 12:12 PM, Michael Wallner m...@php.net wrote: On Tue, 15 Nov 2011 23:51:25 +0100, Patrick ALLAERT wrote: As per rfc6265, it seems incorrect: Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name. @mike Since you are the one who introduced the comment, you might be the best person to comment on this. If you set replace to 1 it would replace any Set-Cookie header, not necessarily the session cookie header. Mike if we fix that, I would like to see https://bugs.php.net/bug.php?id=38104(previously reported as https://bugs.php.net/bug.php?id=31455) fixed also. -- Ferenc Kovács @Tyr43l - http://tyrael.hu bump. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Remove memory leak in PHP5.4 for bug 55971
Hi Stas,
I did run the test of bug #55871 and got memory leaks. This patch
remove them. Could you please review the patch and if it is Ok i'll
commit it to 5.4
Thanks
Pierrick
Index: NEWS
===
--- NEWS(revision 322482)
+++ NEWS(working copy)
@@ -2,6 +2,9 @@
|||
?? Jan 2012, PHP 5.4.0
+- Standard:
+ . Fixed memory leak in substr_replace. (Pierrick)
+
19 Jan 2012, PHP 5.4.0 RC6
- Core:
Index: ext/standard/string.c
===
--- ext/standard/string.c (revision 322482)
+++ ext/standard/string.c (working copy)
@@ -2518,6 +2518,9 @@
if(Z_REFCOUNT_P(orig_str) != refcount) {
php_error_docref(NULL
TSRMLS_CC, E_WARNING, Argument was modified while replacing);
+ if(Z_TYPE_PP(tmp_repl) !=
IS_STRING) {
+ zval_dtor(repl_str);
+ }
break;
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 64bit Windows builds
On 1/19/2012 5:29 AM, Pierre Joye wrote: 2012/1/19 Ángel González keis...@gmail.com: Such binaries wouldn't be compatible with IIS, but mingw seems preferible to the legacy VC6 for use with the oficial Apache binaries. A couple of things to remember; msvcrt.dll is quite actively maintained, even when it's maintained against the interests of php or the c language standards bodies. This would not be true of msvcr70.dll, for example. Actively supported is msvcr100.dll, of VisualStudio 2010, and that is what the httpd project expects to ship some httpd 2.4.0 binaries with. But the msvcrt.dll itself is neither less or more maintained so far than the per-studio-release flavor. It's a shame that the NT/kernel team and the VisualStudio team simply can't get along. Any mingw/gcc build is going to bind right back to msvcrt.dll, nullifying whatever train of thought you were pursuing. There are php-specific defects that MS has chosen to err on the side of incompatibility to spec. There is no such thing like official apache binaries, they provide some as conveniences. Just as with php; these are open source, we give you the source. What you the user proceed to do with it is with our blessings :) This is one of the advantages of keeping build systems and dependencies as accessible as possible, something I consider a flaw in php's win (and aix, solaris and hpux support), and a laudable goal of the coapp effort (all the way through pushing upstream their own shallow fork fixes). -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] salsa.lo
Just updated and tried to compile, getting this: make: *** No rule to make target `/opt/php-core/trunk-accessor/ext/hash/hash_salsa.c', needed by `ext/hash/hash_salsa.lo'. Stop. I see that commit 322421 removed the hash_salsa.c but perhaps the Makefile didn't get updated? Anyone else seeing this? -Clint
Re: [PHP-DEV] salsa.lo
On 01/19/2012 08:20 PM, Clint M Priest wrote: Just updated and tried to compile, getting this: make: *** No rule to make target `/opt/php-core/trunk-accessor/ext/hash/hash_salsa.c', needed by `ext/hash/hash_salsa.lo'. Stop. I see that commit 322421 removed the hash_salsa.c but perhaps the Makefile didn't get updated? Anyone else seeing this? ./buildconf ./configure -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] session_regenerate_id() not replacing Set-Cookie header
Hi! Even if this bug is marked as bogus in bug DB, I think this bug needed to be fixed for 5.4. https://bugs.php.net/bug.php?id=38104 It seems this bug causes problem with IE that not keeping session correctly. It looks like pretty rare scenario and doesn't seem to require any core changes to fix, so I think we can do it in 5.4.1. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Code freeze for 5.4
Hi! Hi Stats, Ok, I'll hold committing to 5.4, but commit it only to trunk. Any comments form anyone? for committing to trunk? Patch details and user land counter measure are in RFC. Re-reading the discussion, I see that the question of why we need separate validator handler is still unresolved. I think we were left with this: In this case, users cannot distinguish whether PS module is adoptive or not. But this can be solved by documentation, unless you mean users in the code - but then I don't see how having new handler would help as PHP code can not really check for this handler, can it? So the question why we need such handler is still open. However if we would have binary compatible patch it probably would be ok for 5.4.1. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove memory leak in PHP5.4 for bug 55971
Hi! I did run the test of bug #55871 and got memory leaks. This patch remove them. Could you please review the patch and if it is Ok i'll commit it to 5.4 Please hold it for now. It's not a critical issue, if we'd have another RC for different reason, we can also have it in as it doesn't look to dangerous. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug 48417 and PHP 5.4
Hey Pierre, I was wondering if you'd be willing to pitch a rollback of r300894 post-code-freeze. If not, I'll start writing error detection code to accomodate for PHP 5.4 :^) Thanks, Edward Excerpts from Edward Z. Yang's message of Sun Jan 08 11:41:50 -0500 2012: Hello Pierre, The whole situation is a slightly complicated. One question to ask is: Is there code in PHP 5.3 that worked, which now no longer works in PHP 5.4? The answer to this question is *yes*, as seen by this example: var_dump(iconv(UTF-8, ISO-8859-1//IGNORE, \xE4\xB8\xAD)); Now, the reason why this worked in PHP 5.3 was because of a bug, namely #52211, so the situation in PHP 5.3 was two wrongs make a right (except, of course, in the case where more than 8000 bytes are involved.) Fixing one of the bugs causes //IGNORE to stop working entirely. So if you ask another question, Are there less bugs in PHP 5.4 than in PHP 5.3, the answer is also yes. Now, consider the perspective of a library developer using iconv //IGNORE. In PHP 5.3, effective workarounds exist: I can fix #52211 by checking for captured errors and returning false instead, I can fix #48147 by splitting my input into 8kb chunks (mumble utf-8 boundaries) and feeding it to iconv individually. In PHP 5.4, I am left with no such redress. Because iconv will now always return false upon an input, regardless of whether or not //IGNORE is set, I can no longer do conversions with invalid inputs. It's worth repeating: #48147 is no longer iconv with //IGNORE cuts string, it's iconv with //IGNORE doesn't work. At all. I *guarantee* you large amounts of PHP code will be affected. It seems it would be better to wait for a complete fix, than to fix it partially and leave some (widely used) functionality completely broken. Is this a bug in glibc? I sincerely hope I can convince Ulrich Drepper so, since I agree that his API is completely off the wall: http://sources.redhat.com/bugzilla/show_bug.cgi?id=13541 But as it stands, Ulrich does not seem to believe that there is any bug (see that he's closed both of my upstream bugs; and, since //IGNORE is wholly undocumented, there is not really any spec I can hold him to), so it would seem most advisable for PHP to play nice, since most users are not in the position to patch their glibc installation. Cheers, Edward Excerpts from Pierre Joye's message of Sun Jan 08 07:36:03 -0500 2012: hi, I closed one bug (unrelated to what you have) and added a comment to the /ignore issue. I do not see a bug in PHP but if you have any info that shows that PHP causes this problem, then please add them to the bug so we can fix it, if not I will bogus it as there is no bug in php but in iconv (glibc or other implementations). On Thu, Jan 5, 2012 at 7:42 PM, Edward Z. Yang ezy...@php.net wrote: Hello all, I know it seems like there always is infinite pile of work to do before the PHP 5.4 release comes out, but I think this bug is worth looking at. https://bugs.php.net/bug.php?id=52211 I suggest reverting r300894, since this causes //IGNORE to stop working. Preserving functionality should probably be more important. The underlying cause of this bug is this one: https://bugs.php.net/bug.php?id=48147 But I don't think this feature is going to get implemented in time. Edward -- 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
