[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
On 09/06/2011 10:45 AM, Stas Malyshev wrote:
Hi!
On 9/6/11 1:24 AM, Andrey Hristov wrote:
no, it's about consistency, which you want. mysqlnd should behave like
libmysql, and it is a test that can test it. What libmysql returns in
filtered in mysqli, mysqli_num_rows() is a direct wrapper around
mysql_num_rows(), and this is what we test.
Sorry, I don't understand. mysqlnd returns non-zero number of rows after
last fetch, libmysql does not, and that's what you test for. Are you
saying it's a bug in libmysql or mysqli driver that it doesn't return
that number?
Have you actually checked what libmysql returns??!?
If _you_ just have tried to do it, you might actually find that libmysql
does what mysqlnd did long ago, but mysqli was hiding it. Here is output
from what libmysql does, after removing the following check from
mysqli_api.c:
// if (mysqli_result_is_unbuffered_and_not_everything_is_fetched(result)) {
// php_error_docref(NULL TSRMLS_CC, E_WARNING, Function cannot be used
with MYSQL_USE_RESULT);
// RETURN_LONG(0);
// }
Read and learn:
- libmysql -
andrey@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php_libmysql
-r
'$c=mysqli_connect(127.0.0.1,root,root,test);$c-real_query(SELECT
42 FROM mysql.user LIMIT
2);$res=$c-use_result();printf(num_rows=%d\n,
mysqli_num_rows($res)); var_dump($res-fetch_assoc());
printf(num_rows=%d\n, mysqli_num_rows($res));
var_dump($res-fetch_assoc()); printf(num_rows=%d\n,
mysqli_num_rows($res)); var_dump($res-fetch_assoc());
printf(num_rows=%d\n, mysqli_num_rows($res));'
num_rows=0
array(1) {
[42]=
string(2) 42
}
num_rows=1
array(1) {
[42]=
string(2) 42
}
num_rows=2
NULL
num_rows=2
-- mysqlnd
andrey@poohie:/work/vanilla/php/php-src/branches/PHP_5_3$ ./php_mysqlnd
-r
'$c=mysqli_connect(127.0.0.1,root,root,test);$c-real_query(SELECT
42 FROM mysql.user LIMIT
2);$res=$c-use_result();printf(num_rows=%d\n,
mysqli_num_rows($res)); var_dump($res-fetch_assoc());
printf(num_rows=%d\n, mysqli_num_rows($res));
var_dump($res-fetch_assoc()); printf(num_rows=%d\n,
mysqli_num_rows($res)); var_dump($res-fetch_assoc());
printf(num_rows=%d\n, mysqli_num_rows($res));'
num_rows=0
array(1) {
[42]=
string(2) 42
}
num_rows=0
array(1) {
[42]=
string(2) 42
}
num_rows=0
NULL
num_rows=2
---
As you can see, libmysql returns different numbers, it increments the
number of rows. The used client library is 5.1.54, which is stock from
Ubuntu 11.04 .
Best,
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
Hi! Have you actually checked what libmysql returns??!? If _you_ just have tried to do it, you might actually find that libmysql does what mysqlnd did long ago, but mysqli was hiding it. Here is output from what libmysql does, after removing the following check from mysqli_api.c: I checked what my build of PHP returns (which was build against libmysql) and it always returns 0. Now I want to understand why it happens - is it a bug in libmysql, in mysqli handling results or in something else? I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)-handle (r)-handle-status == MYSQL_STATUS_USE_RESULT) || ((r)-data == NULL)) When I step through your code, r-data (which is result-data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? -- 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] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
On 09/06/2011 11:16 AM, Stas Malyshev wrote: Hi! Have you actually checked what libmysql returns??!? If _you_ just have tried to do it, you might actually find that libmysql does what mysqlnd did long ago, but mysqli was hiding it. Here is output from what libmysql does, after removing the following check from mysqli_api.c: I checked what my build of PHP returns (which was build against libmysql) and it always returns 0. Now I want to understand why it happens - is it a bug in libmysql, in mysqli handling results or in something else? I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)-handle (r)-handle-status == MYSQL_STATUS_USE_RESULT) || ((r)-data == NULL)) When I step through your code, r-data (which is result-data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? what kind of a Problem? Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 05.09.2011 11:08, schrieb Stas Malyshev: Hi! On 9/5/11 1:24 AM, Andrey Hristov wrote: the problem is that libmysql breaks, maybe more often than mysqlnd does. We rarely find bugs in mysqli, there are two codepaths in mysqli. If there is a bug in libmysql, what do you want: If we're dealing with libmysql bug, then I guess the expected thing would be to report it upstream, and make the comment in the test with bug ID. But in the cases I mentioned it does not look like libmysql bug as everything works just according to Mysql documentation, however the tests expect it to work differently. Stas, what are we going to do now after the discussion has calmed down a bit? Any new PHP major release is about setting new directions. I, Andrey and Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd after an incubation of some four years (5.3x series + dev time). You, in your role as 5.4 RM, raised some concerns about changing the default to mysqlnd. Your primary concern is rolling out something that breaks PHP. As an example, you have listed some mysqli test failures. After the weekend, I'm a lazy bastard refusing to work during weekends, test failures have been commented on: - connect_oo_* - libmysql only, no BC [1] - explain_meta - libmysql can crash PHP, mysqlnd works [2] - stmt_num_rows - differences in undefined behaviour [3] - insert_id - as a bug, it would be bogussed, undefined [4] Your four examples stand up against, for example, Pierre Windows Joye. The php.net windows binaries are using mysqlnd as of PHP 5.3. Windows is probaly the biggest individual distribution. Pierre, who is no MySQL fan boy, reports no BC issues. This is based on multiple years of php.net Windows users feedback and his continous integration testing using drupal 67, wp, oscommerce, mediawiki, sugarcrm, etc. [5]. At least on Windows, users do expect to see mysqlnd meanwhile. Harald Reindl did the switch from libmysql to mysqlnd on hundret domains with no single problem [6]. OpenSuSE did the same. As a manager, you often have to make a decision without knowing all details, without checking everything yourself. You have named and set the #1 risk (BC) and heard people's opinion: mysqlnd is not flawless, but well worth a try. You also raised the question how or if a change will impact packagers. Tomas Kuliavas gave some great input on this [7]: SuSE: --with-mysql=shared,mysqlnd Debian, Mandriva and Fedora: --with-mysql=shared,/usr --with-mysqli=shared,/usr/bin/mysql_config' Looks like packages explicitly set config options. Thus, no break provoked if changing defaults. There's a bit of a buzz on shared builds, Johannes is working on that one - https://bugs.php.net/bug.php?id=55609 . IMHO all of the relevant concerns have been adressed. No high risks have been found. There is nothing in the way that cannot be tackled down as one moves forward. I see no reason for ignoring the vote of the maintainers. I fail to understand why PHP @ *nix should not catch up to Windows. Ulf [1] http://news.php.net/php.internals/55226 [2] http://news.php.net/php.internals/55221 [3] http://news.php.net/php.internals/55210 [4] http://news.php.net/php.internals/55228 [5] http://news.php.net/php.internals/55177 [6] http://news.php.net/php.internals/55174 [7] http://news.php.net/php.internals/55142 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 答复: [PHP-DEV] full LFS support
On Tue, Aug 17, 2010 at 4:22 PM, Ferenc Kovacs i...@tyrael.hu wrote: Hi. I would like to know what is the current status of the LFS support for php. http://bugs.php.net/bug.php?id=27792 http://bugs.php.net/bug.php?id=48886 As far as I can see, there are some patches floating around, but some of them doesn't work, some of them are incomplete. As far as I can see, with the latest release(5.3.3) you can't stat or filesize a file where the size is = 2GiB on 32bit OS, and = 4GiB on 64bit. Is this true? From the proposed patches, it seems that there arent that many LOC which needs to be adjusted to provide a decent LFS support. Are there any blocker objections or architectural problems, or we just lack specification or manpower to fix this issue? If this gets fixed, will this be included into the 5.3 branch, or this can only be added with the next major version? Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php bump. Tyrael bump (hoping that maybe laruence or Felipe takes a look) Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 答复: [PHP-DEV] full LFS support
AFAIK Pierre has some point about Windows part. 2011/9/6 Ferenc Kovacs i...@tyrael.hu: On Tue, Aug 17, 2010 at 4:22 PM, Ferenc Kovacs i...@tyrael.hu wrote: Hi. I would like to know what is the current status of the LFS support for php. http://bugs.php.net/bug.php?id=27792 http://bugs.php.net/bug.php?id=48886 As far as I can see, there are some patches floating around, but some of them doesn't work, some of them are incomplete. As far as I can see, with the latest release(5.3.3) you can't stat or filesize a file where the size is = 2GiB on 32bit OS, and = 4GiB on 64bit. Is this true? From the proposed patches, it seems that there arent that many LOC which needs to be adjusted to provide a decent LFS support. Are there any blocker objections or architectural problems, or we just lack specification or manpower to fix this issue? If this gets fixed, will this be included into the 5.3 branch, or this can only be added with the next major version? Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php bump. Tyrael bump (hoping that maybe laruence or Felipe takes a look) Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Borked SKIPIFs (PHP_5_4)
Hi,
annoyed by run-tests.php ignoring borked SKIPIF sections, I hacked it to
bail out at me if something seemed suspicious. Maintainers may want to
have a look at:
Fatal/Parse error @ SKIPIF = SKIPIF non functional
BORK 883/9126 [Zend/tests/bug31683.phpt]
BORK 4037/9248 [ext/phar/tests/fopen_edgecases2.phpt
BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt]
BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt]
Warnings/Notices @ SKIPIF = SKIPIF should work fine
BORK 4451/9248 [ext/posix/tests/posix_getpgid_error.phpt]
BORK 4452/9248 [ext/posix/test/posix_getpgid_variation.phpt]
BORK 4865/9248 [ext/session/test/rfc1867_invalid_settings.phpt]
BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt]
My PHP was built with pretty much nothing but MySQL stuff enabled. A
fair number of tests has probably been skipped.
The run-tests.php hack I used is not worth sharing. All I did was check
if SKIPIF returns any output after removal of -d display_errors=0. In
other words I made the assumption that SKIPIF sections must not output
anything but skip message or the like, which causes false positives.
Ulf
Details:
BORK 883/9126 [Zend/tests/bug31683.phpt]
Warning: require_once(skipif.inc): failed to open stream: No such file
or directory in
/home/nixnutz/php/php-src/branches/PHP_5_4/Zend/tests/bug31683.skip.php
on line 1
Fatal error: require_once(): Failed opening required 'skipif.inc'
(include_path='.:/usr/local/lib/php') in
/home/nixnutz/php/php-src/branches/PHP_5_4/Zend/tests/bug31683.skip.php
on line 1
BORK 4037/9248 [ext/phar/tests/fopen_edgecases2.phpt
Fatal error: Call to undefined function php_version() in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/phar/tests/fopen_edgecases2.skip.php
on line 2
BORK 4451/9248 [ext/posix/tests/posix_getpgid_error.phpt]
Notice: Use of undefined constant posix_getpgid - assumed
'posix_getpgid' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/posix/tests/posix_getpgid_error.skip.php
on line 2
[] ext/posix/tests/posix_getpgid_error.phpt
BORK 4452/9248 [ext/posix/test/posix_getpgid_variation.phpt]
Notice: Use of undefined constant posix_getpgid - assumed
'posix_getpgid' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/posix/tests/posix_getpgid_variation.skip.php
on line 2
BORK 4865/9248 [ext/session/test/rfc1867_invalid_settings.phpt]
Warning: PHP Startup: session.upload_progress.freq must be greater than
or equal to zero in Unknown on line 0
BORK 4866/9248 [ext/session/tests/rfc1867_invalid_settings_2.phpt]
Warning: PHP Startup: session.upload_progress.freq cannot be over 100%
in Unknown on line 0
BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt]
Warning: include(skipif.inc): failed to open stream: No such file or
directory in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/file/php_fd_wrapper_04.skip.php
on line 1
Warning: include(): Failed opening 'skipif.inc' for inclusion
(include_path='.:/usr/local/lib/php') in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/file/php_fd_wrapper_04.skip.php
in line 1
BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt]
Parse error: syntax error, unexpected '!', expecting '(' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/strings/md5_file.skip.php
on line 6
BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt]
Parse error: syntax error, unexpected '!', expecting '(' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/strings/sha1_file.skip.php
on line 6
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] zlib issues in 5.4 and trunk
hi, It seems that 5.4 and trunk has something broken in zlib and maybe bas64 encoding/decoding. We have a serie of tests failing on linux or windows: ext\zlib\tests\bug_52944.phpt ext\zlib\tests\gzcompress_basic1.phpt ext\zlib\tests\gzcompress_variation1.phpt ext\zlib\tests\gzdeflate_basic1.phpt ext\zlib\tests\gzdeflate_variation1.phpt ext\zlib\tests\gzencode_basic1.phpt ext\zlib\tests\gzencode_variation1-win32.phpt (the unix version too) ext\zlib\tests\gzfile_basic.phpt ext\zlib\tests\gzfile_basic2.phpt \tests\gzfilegzreadfile.phpt ext\zlib\tests\gzuncompress_basic1.phpt ext\zlib\tests\readgzfile_basic.phpt ext\zlib\tests\readgzfile_basic2.phpt cheers, -- 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] Borked SKIPIFs (PHP_5_4)
hi Ulf,
I fixed two. Feel free to fix the other as well if you have time.
On Tue, Sep 6, 2011 at 4:40 PM, Ulf Wendel ulf.wen...@oracle.com wrote:
Hi,
annoyed by run-tests.php ignoring borked SKIPIF sections, I hacked it to
bail out at me if something seemed suspicious. Maintainers may want to have
a look at:
Fatal/Parse error @ SKIPIF = SKIPIF non functional
BORK 883/9126 [Zend/tests/bug31683.phpt]
BORK 4037/9248 [ext/phar/tests/fopen_edgecases2.phpt
BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt]
BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt]
Warnings/Notices @ SKIPIF = SKIPIF should work fine
BORK 4451/9248 [ext/posix/tests/posix_getpgid_error.phpt]
BORK 4452/9248 [ext/posix/test/posix_getpgid_variation.phpt]
BORK 4865/9248 [ext/session/test/rfc1867_invalid_settings.phpt]
BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt]
My PHP was built with pretty much nothing but MySQL stuff enabled. A fair
number of tests has probably been skipped.
The run-tests.php hack I used is not worth sharing. All I did was check if
SKIPIF returns any output after removal of -d display_errors=0. In other
words I made the assumption that SKIPIF sections must not output anything
but skip message or the like, which causes false positives.
Ulf
Details:
BORK 883/9126 [Zend/tests/bug31683.phpt]
Warning: require_once(skipif.inc): failed to open stream: No such file or
directory in
/home/nixnutz/php/php-src/branches/PHP_5_4/Zend/tests/bug31683.skip.php on
line 1
Fatal error: require_once(): Failed opening required 'skipif.inc'
(include_path='.:/usr/local/lib/php') in
/home/nixnutz/php/php-src/branches/PHP_5_4/Zend/tests/bug31683.skip.php on
line 1
BORK 4037/9248 [ext/phar/tests/fopen_edgecases2.phpt
Fatal error: Call to undefined function php_version() in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/phar/tests/fopen_edgecases2.skip.php
on line 2
BORK 4451/9248 [ext/posix/tests/posix_getpgid_error.phpt]
Notice: Use of undefined constant posix_getpgid - assumed 'posix_getpgid' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/posix/tests/posix_getpgid_error.skip.php
on line 2
[] ext/posix/tests/posix_getpgid_error.phpt
BORK 4452/9248 [ext/posix/test/posix_getpgid_variation.phpt]
Notice: Use of undefined constant posix_getpgid - assumed 'posix_getpgid' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/posix/tests/posix_getpgid_variation.skip.php
on line 2
BORK 4865/9248 [ext/session/test/rfc1867_invalid_settings.phpt]
Warning: PHP Startup: session.upload_progress.freq must be greater than or
equal to zero in Unknown on line 0
BORK 4866/9248 [ext/session/tests/rfc1867_invalid_settings_2.phpt]
Warning: PHP Startup: session.upload_progress.freq cannot be over 100% in
Unknown on line 0
BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt]
Warning: include(skipif.inc): failed to open stream: No such file or
directory in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/file/php_fd_wrapper_04.skip.php
on line 1
Warning: include(): Failed opening 'skipif.inc' for inclusion
(include_path='.:/usr/local/lib/php') in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/file/php_fd_wrapper_04.skip.php
in line 1
BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt]
Parse error: syntax error, unexpected '!', expecting '(' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/strings/md5_file.skip.php
on line 6
BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt]
Parse error: syntax error, unexpected '!', expecting '(' in
/home/nixnutz/php/php-src/branches/PHP_5_4/ext/standard/tests/strings/sha1_file.skip.php
on line 6
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
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] Borked SKIPIFs (PHP_5_4)
Hi Pierre, hi all, those three should be left: BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt] BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt] BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt] They might take more than 1 second (verbally) to fix. Leaving to someone else to have a 30 seconds look... ;-) Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
Hi! On 9/6/11 2:46 AM, Andrey Hristov wrote: I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)-handle (r)-handle-status == MYSQL_STATUS_USE_RESULT) || ((r)-data == NULL)) When I step through your code, r-data (which is result-data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? what kind of a Problem? Please read above. The above says php with libmysql does not return the result the tests expects - instead of returning number of rows after the last fetch it still returns 0. While mysqlnd does not return 0. I would like to know what is causing this and why php+libmysql result is different from what your test expects. -- 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] zlib issues in 5.4 and trunk
Hi! On 9/6/11 8:59 AM, Pierre Joye wrote: hi, It seems that 5.4 and trunk has something broken in zlib and maybe bas64 encoding/decoding. We have a serie of tests failing on linux or windows: Interestingly enough, none of these fail for me on Darwin. Could you publish the diffs? -- 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] Borked SKIPIFs (PHP_5_4)
On Tue, Sep 6, 2011 at 6:53 PM, Ulf Wendel ulf.wen...@oracle.com wrote: Hi Pierre, hi all, those three should be left: BORK 8514/9248 [ext/standard/tests/strings/sha1_file.phpt] BORK 8443/9248 [ext/standard/tests/strings/md5_file.phpt] those are fixed already :) BORK 7328/9248 [ext/standard/tests/file/php_fd_wrapper_04.phpt] They might take more than 1 second (verbally) to fix. Leaving to someone else to have a 30 seconds look... ;-) Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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] zlib issues in 5.4 and trunk
Hi! On 9/6/11 10:05 AM, Pierre Joye wrote: here you go (from win) It fails variously on linux or windows. Laruence reproduces the fails on linux too, some segfault from time to time. Hmm... Kind of hard to go on from time to time - are you sure there's no build/old library issue? Do we have a reproduction for the segfaults? The diffs look like your gzip is producing different data - I wonder if some version might be doing something slightly different. -- 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] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
Stas,
On 09/06/2011 06:55 PM, Stas Malyshev wrote:
Hi!
On 9/6/11 2:46 AM, Andrey Hristov wrote:
I've looked into
mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks
like for libmysql it checks this:
(((r)-handle (r)-handle-status == MYSQL_STATUS_USE_RESULT) ||
((r)-data == NULL))
When I step through your code, r-data (which is result-data) is always
NULL for me, which means warning is generated and 0 is returned. Is it a
problem in libmysql?
what kind of a Problem?
Please read above. The above says php with libmysql does not return the
result the tests expects - instead of returning number of rows after the
last fetch it still returns 0. While mysqlnd does not return 0. I would
like to know what is causing this and why php+libmysql result is
different from what your test expects.
r-data should be always NULL, for an unbuffered fetch, r-data holds
the data for buffered result sets. It is additional protection, an
assert. I don't see a problem with that. I don't see also the behavior
you describe - 0 returned even after the last fetch. If all data is
fetched r-handle-status will be no more MYSQL_STATUS_USE_RESULT but
something else (MYSQL_STATUS_READY), this will signal, that everything
has been fetched. Of course, the check could have been !res-eof, but
this is not what Georg chose long ago (see 5_2) :
if (result-handle result-handle-status == MYSQL_STATUS_USE_RESULT) {
On my box the test passes both with libmysql and mysqlnd. What I did was
to create consistent behavior, something people expect, although
libmysql returns something different, which was mysqlnd's behavior in
the beginning too.
Andrey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zlib issues in 5.4 and trunk
On Tue, Sep 6, 2011 at 8:03 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hmm... Kind of hard to go on from time to time - are you sure there's no build/old library issue? Do we have a reproduction for the segfaults? The diffs look like your gzip is producing different data - I wonder if some version might be doing something slightly different. Yes, we use the same libs for 5.3 and 5.4 and same tests pass in 5.3. Bu it is also reproducible on many unrelated hosts. Laruence will be back tomorrow, I will ask him to provide his diffs too (and some bt) -- 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] zlib issues in 5.4 and trunk
Hi! On 9/6/11 11:35 AM, Pierre Joye wrote: Yes, we use the same libs for 5.3 and 5.4 and same tests pass in 5.3. Bu it is also reproducible on many unrelated hosts. Well, maybe somebody that could reproduce it could look into it? Because I'm unable to reproduce any of it... -- 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] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
Hi! On 9/6/11 11:05 AM, Andrey Hristov wrote: I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)-handle (r)-handle-status == MYSQL_STATUS_USE_RESULT) || ((r)-data == NULL)) When I step through your code, r-data (which is result-data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? r-data should be always NULL, for an unbuffered fetch, r-data holds the data for buffered result sets. It is additional protection, an If r-data is always null, then - please look at the code above - mysqli_result_is_unbuffered_and_not_everything_is_fetched() is always true. Which I think is not what was intended, because the test implies otherwise, but maybe I am mistaken. That's what I am trying to find out - is this behavior of libmysql/mysqli implementation, that always returns 0 and produces an error for use results for num_rows - intentional or is it some kind of error. assert. I don't see a problem with that. I don't see also the behavior you describe - 0 returned even after the last fetch. If all data is fetched r-handle-status will be no more MYSQL_STATUS_USE_RESULT but something else (MYSQL_STATUS_READY), this will signal, that everything has been fetched. Of course, the check could have been !res-eof, but This is true, however if you look at the condition, it returns true always when r-data us NULL regardless of what is there in the status. What I am trying to find out is if this behavior is intended - and then the test is wrong for this situation - or is it not intended and needs to be fixed. -- 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] zlib issues in 5.4 and trunk
On Tue, Sep 6, 2011 at 9:03 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 9/6/11 11:35 AM, Pierre Joye wrote: Yes, we use the same libs for 5.3 and 5.4 and same tests pass in 5.3. Bu it is also reproducible on many unrelated hosts. Well, maybe somebody that could reproduce it could look into it? Because I'm unable to reproduce any of it... Really? three linux (ubuntu latest and debian 5/6 here) as well on windows. -- 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] Make mysqlnd default over libmysql in 5.4
Hi! Any new PHP major release is about setting new directions. I, Andrey and Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd after an incubation of some four years (5.3x series + dev time). My concern was also that making mysqlnd the default would make libmysql support considered secondary and unimportant. As I was assured it is not the case and the differences between mysqlnd and libmysql flavors seem to be rectified or in the process of being rectified, and I heard no objections for this as a default, I'm OK with it 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] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
On 09/06/2011 09:08 PM, Stas Malyshev wrote: Hi! On 9/6/11 11:05 AM, Andrey Hristov wrote: I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)-handle (r)-handle-status == MYSQL_STATUS_USE_RESULT) || ((r)-data == NULL)) When I step through your code, r-data (which is result-data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? r-data should be always NULL, for an unbuffered fetch, r-data holds the data for buffered result sets. It is additional protection, an If r-data is always null, then - please look at the code above - mysqli_result_is_unbuffered_and_not_everything_is_fetched() is always true. Which I think is not what was intended, because the test implies otherwise, but maybe I am mistaken. That's what I am trying to find out - is this behavior of libmysql/mysqli implementation, that always returns 0 and produces an error for use results for num_rows - intentional or is it some kind of error. assert. I don't see a problem with that. I don't see also the behavior you describe - 0 returned even after the last fetch. If all data is fetched r-handle-status will be no more MYSQL_STATUS_USE_RESULT but something else (MYSQL_STATUS_READY), this will signal, that everything has been fetched. Of course, the check could have been !res-eof, but This is true, however if you look at the condition, it returns true always when r-data us NULL regardless of what is there in the status. What I am trying to find out is if this behavior is intended - and then the test is wrong for this situation - or is it not intended and needs to be fixed. Good catch. I just fixed it in svn. There is one more remaining issue. mysqli_num_rows() returns different value than mysqli::num_rows due to the way properties are implemented - most properties call directly the underlying function. In this case for libmysql there is difference. mysqli@ should deliver the expected 0 when !EOF. Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/ext/mysqli/tests/bug55582.phpt trunk/ext/mysqli/tests/bug55582.phpt
On 09/06/2011 09:54 PM, Andrey Hristov wrote: On 09/06/2011 09:08 PM, Stas Malyshev wrote: Hi! On 9/6/11 11:05 AM, Andrey Hristov wrote: I've looked into mysqli_result_is_unbuffered_and_not_everything_is_fetched() and it looks like for libmysql it checks this: (((r)-handle (r)-handle-status == MYSQL_STATUS_USE_RESULT) || ((r)-data == NULL)) When I step through your code, r-data (which is result-data) is always NULL for me, which means warning is generated and 0 is returned. Is it a problem in libmysql? r-data should be always NULL, for an unbuffered fetch, r-data holds the data for buffered result sets. It is additional protection, an If r-data is always null, then - please look at the code above - mysqli_result_is_unbuffered_and_not_everything_is_fetched() is always true. Which I think is not what was intended, because the test implies otherwise, but maybe I am mistaken. That's what I am trying to find out - is this behavior of libmysql/mysqli implementation, that always returns 0 and produces an error for use results for num_rows - intentional or is it some kind of error. assert. I don't see a problem with that. I don't see also the behavior you describe - 0 returned even after the last fetch. If all data is fetched r-handle-status will be no more MYSQL_STATUS_USE_RESULT but something else (MYSQL_STATUS_READY), this will signal, that everything has been fetched. Of course, the check could have been !res-eof, but This is true, however if you look at the condition, it returns true always when r-data us NULL regardless of what is there in the status. What I am trying to find out is if this behavior is intended - and then the test is wrong for this situation - or is it not intended and needs to be fixed. Good catch. I just fixed it in svn. There is one more remaining issue. mysqli_num_rows() returns different value than mysqli::num_rows due to the way properties are implemented - most properties call directly the underlying function. In this case for libmysql there is difference. mysqli@ should deliver the expected 0 when !EOF. I mean mysqli@mysqlnd Andrey Andrey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [SPAM?]: Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
Am 06.09.2011 21:33, schrieb Stas Malyshev: Hi! Any new PHP major release is about setting new directions. I, Andrey and Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd after an incubation of some four years (5.3x series + dev time). My concern was also that making mysqlnd the default would make libmysql support considered secondary and unimportant. As I was assured it is not the case and the differences between mysqlnd and libmysql flavors seem to be rectified or in the process of being rectified, and I heard no objections for this as a default, I'm OK with it now. Jippie! Removing libmysql support would be crazy. Not only from a PHP perspective but also from a MySQL one. For PHP it is a must-have fallback option. For MySQL the PHP stuff is a nice libmysql test drive. Not a welcome job among the mysqlnd fan boys, as you noticed. But then, sometimes we count mysqlnd vs. libmysql issues... Ulf -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zlib issues in 5.4 and trunk
On Tue, Sep 6, 2011 at 21:09, Pierre Joye pierre@gmail.com wrote: On Tue, Sep 6, 2011 at 9:03 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 9/6/11 11:35 AM, Pierre Joye wrote: Yes, we use the same libs for 5.3 and 5.4 and same tests pass in 5.3. Bu it is also reproducible on many unrelated hosts. Well, maybe somebody that could reproduce it could look into it? Because I'm unable to reproduce any of it... Really? three linux (ubuntu latest and debian 5/6 here) as well on windows. What is Ubuntu latest? is that 11.04 or the current beta? I'm running Ubuntu 11.04, and none of these fail for me. Two skipped (win only), and one expected to fail due to bug #47178 it seems. Please be a darling and post the diff so we can have something to look at. Maybe seeing the output could jumpstart someones memory and help you debug it. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] zlib issues in 5.4 and trunk
On Wed, Sep 7, 2011 at 1:26 AM, Hannes Magnusson hannes.magnus...@gmail.com wrote: On Tue, Sep 6, 2011 at 21:09, Pierre Joye pierre@gmail.com wrote: On Tue, Sep 6, 2011 at 9:03 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 9/6/11 11:35 AM, Pierre Joye wrote: Yes, we use the same libs for 5.3 and 5.4 and same tests pass in 5.3. Bu it is also reproducible on many unrelated hosts. Well, maybe somebody that could reproduce it could look into it? Because I'm unable to reproduce any of it... Really? three linux (ubuntu latest and debian 5/6 here) as well on windows. What is Ubuntu latest? is that 11.04 or the current beta? I'm running Ubuntu 11.04, and none of these fail for me. Two skipped (win only), and one expected to fail due to bug #47178 it seems. Please be a darling and post the diff so we can have something to look at. Maybe seeing the output could jumpstart someones memory and help you debug it. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php those tests passes on my debian squeeze(amd64) tyrael@phpize:~/checkouts/php-src/trunk$ TEST_PHP_EXECUTABLE=sapi/cli/php sapi/cli/php run-tests.php -g SKIP,XFAIL,FAIL -n -c tmp-php.ini ext/zlib/ = PHP : sapi/cli/php PHP_SAPI: cli PHP_VERSION : 5.5.0-dev ZEND_VERSION: 2.4.0 PHP_OS : Linux - Linux phpize 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC 2011 x86_64 INI actual : /home/tyrael/checkouts/php-src/trunk More .INIs : CWD : /home/tyrael/checkouts/php-src/trunk Extra dirs : VALGRIND: Not used = Running selected tests. SKIP Test gzencode() function : variation [ext/zlib/tests/gzencode_variation1-win32.phpt] reason: only for Windows SKIP Test gzencode() function : variation - verify header contents with all encoding modes [ext/zlib/tests/gzencode_variation2-win32.phpt] reason: .. only for Windows XFAIL Test gzencode() function : variation - verify header contents with all encoding modes [ext/zlib/tests/gzencode_variation2.phpt] XFAIL REASON: Test will fail until bug #47178 resolved; missing gzip headers when FORCE_DEFLATE specified = Number of tests : 146 144 Tests skipped :2 ( 1.4%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Expected fail :1 ( 0.7%) ( 0.7%) Tests passed: 143 ( 97.9%) ( 99.3%) - Time taken : 10 seconds = = EXPECTED FAILED TEST SUMMARY - Test gzencode() function : variation - verify header contents with all encoding modes [ext/zlib/tests/gzencode_variation2.phpt] XFAIL REASON: Test will fail until bug #47178 resolved; missing gzip headers when FORCE_DEFLATE specified = -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Weak References
Hi, On Sat, Sep 3, 2011 at 19:21, Nicolas Grekas nicolas.grekas+...@gmail.comwrote: $pseudoWeakMap = array(); $pseudoWeakMap[spl_object_**hash($obj)] = new WeakReference($obj); or did I misunderstand the concept? I hope I'll have a chance to use WeakReferences soon in my project;) I also believe that this is the logic, but from the doc, when an object is destroyed, its hash may be reused for other objects. So this implementation could possibly have bad side effect, isn't it ? Nicolas I don't understand how the code you just gave would be useful in practice? I've implemented a WeakMap class in the weakref pecl ext, see: http://svn.php.net/viewvc/pecl/weakref/trunk/tests/weakmap_001.phpt?revision=316293view=markup for an example of usage. I believe this better fit people's needs. Or did you have something else in mind? Best, -- Etienne Kneuss http://www.colder.ch
Re: [PHP-DEV] zlib issues in 5.4 and trunk
Hi: ext/zlib/tests/gzencode_variation1.phpt failed in Linux(redhat 64-bit) test log http://pastebin.com/TzpW8GTK thanks 2011/9/6 Pierre Joye pierre@gmail.com: hi, It seems that 5.4 and trunk has something broken in zlib and maybe bas64 encoding/decoding. We have a serie of tests failing on linux or windows: ext\zlib\tests\bug_52944.phpt ext\zlib\tests\gzcompress_basic1.phpt ext\zlib\tests\gzcompress_variation1.phpt ext\zlib\tests\gzdeflate_basic1.phpt ext\zlib\tests\gzdeflate_variation1.phpt ext\zlib\tests\gzencode_basic1.phpt ext\zlib\tests\gzencode_variation1-win32.phpt (the unix version too) ext\zlib\tests\gzfile_basic.phpt ext\zlib\tests\gzfile_basic2.phpt \tests\gzfilegzreadfile.phpt ext\zlib\tests\gzuncompress_basic1.phpt ext\zlib\tests\readgzfile_basic.phpt ext\zlib\tests\readgzfile_basic2.phpt cheers, -- 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 -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Compiling warnings should be fixed
Hi: there is a lot of compiling warnings in truk(branch also), I have fixed most of them unless those in Zend/* here is the warning log: http://pastebin.com/ah3qtP6A (compile with I think it is better to fix them all, since we should release a perfect project(although most of them are no issue) of course I can do it, but need a zend karma. thanks -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CI for 5.4
Hi! Since we started to pay real attention to our unit tests now, I wonder if we could set up some kind of frequently-running CI system that could be used to screen commits and identify breakage early? That'd help with 5.4 process I think. We have http://gcov.php.net/ but it doesn't run with the frequency I'd like and since it says the run takes 44 hours it's kind of understandable. So I wonder if we could have something that just builds it and runs unit tests and we could see it in the same format as on gcov? Ideally after each commit would be nice, but say once an hour or two (even fullest unit tests run should take more than that, I think) would be OK too. If we could have two of them, like Linux Windows, it'd be even better, but at least one would be nice. What do you think? -- 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] CI for 5.4
+1 thanks 2011/9/7 Stas Malyshev smalys...@sugarcrm.com: Hi! Since we started to pay real attention to our unit tests now, I wonder if we could set up some kind of frequently-running CI system that could be used to screen commits and identify breakage early? That'd help with 5.4 process I think. We have http://gcov.php.net/ but it doesn't run with the frequency I'd like and since it says the run takes 44 hours it's kind of understandable. So I wonder if we could have something that just builds it and runs unit tests and we could see it in the same format as on gcov? Ideally after each commit would be nice, but say once an hour or two (even fullest unit tests run should take more than that, I think) would be OK too. If we could have two of them, like Linux Windows, it'd be even better, but at least one would be nice. What do you think? -- 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 -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CI for 5.4
On Wed, Sep 7, 2011 at 3:29 AM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Since we started to pay real attention to our unit tests now, I wonder if we could set up some kind of frequently-running CI system that could be used to screen commits and identify breakage early? That'd help with 5.4 process I think. We have http://gcov.php.net/ but it doesn't run with the frequency I'd like and since it says the run takes 44 hours it's kind of understandable. So I wonder if we could have something that just builds it and runs unit tests and we could see it in the same format as on gcov? Ideally after each commit would be nice, but say once an hour or two (even fullest unit tests run should take more than that, I think) would be OK too. If we could have two of them, like Linux Windows, it'd be even better, but at least one would be nice. What do you think? -- 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 Hi, I also support the idea. I would suggest setting up a jenkins(ex-hudson) cluster, it is the leading CI product on the market (and a really successful open source project), and it is really well-known in the php community as well, and because I have used for my other projects in the past(not just for php, but for some C apps also). Jenkins supports having multiple slave instances running on different platforms, nicely bound together, so you only access the master instance through your browser, but the builds itself can be off-loaded to the slaves ( https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds ). I would be happy to help setting it up. -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [SPAM?]: Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4
2011.09.06 23:20 Ulf Wendel rašė: Am 06.09.2011 21:33, schrieb Stas Malyshev: Hi! Any new PHP major release is about setting new directions. I, Andrey and Johannes, the guys maintaining ext/*mysql* recommend going mysqlnd after an incubation of some four years (5.3x series + dev time). My concern was also that making mysqlnd the default would make libmysql support considered secondary and unimportant. As I was assured it is not the case and the differences between mysqlnd and libmysql flavors seem to be rectified or in the process of being rectified, and I heard no objections for this as a default, I'm OK with it now. Jippie! Removing libmysql support would be crazy. Not only from a PHP perspective but also from a MySQL one. For PHP it is a must-have fallback option. For MySQL the PHP stuff is a nice libmysql test drive. Not a welcome job among the mysqlnd fan boys, as you noticed. But then, sometimes we count mysqlnd vs. libmysql issues... Bouncing bug reports (https://bugs.php.net/bug.php?id=55001) that are not reproducible on setup with mysqlnd when user reports about issue with libmysql is not the way bugs are solved. mysqlnd is not authoritative source for mysql extension behavior. libmysql is. That bug report shows semantics differences Stas was talking about and bug status shows the way you are handling it. If libmysql semantics change between versions, indicate that in bug report instead refusing to solve the problem with 'mysqlnd works fine' -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
