#34075 [Fbk-Csd]: The ext/standard/tests/file/bug22414.phpt script fails

[RVaughn at pheedo dot com]

 ID:   34075
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
-Status:   Feedback
+Status:   Closed
 Bug Type: *General Issues
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

Then I can't convince you.  PHP 4.4.0 is supposed to be the latest
supported 4.x release, and if it doesn't work for that, that should
be enough.

This test script hasn't worked from 4.3.2 through 4.4.0 on four
different releases I've tried.  Unfortunately, like most working
people, I don't have the time to stay on top of my regular workload
already, and definitely do not have the time to download, configure and
compile PHP 5.1 to see whether or not it fails there, esp. when we have
no need for PHP 5.1 right now.

I'm unclear why that would even matter?  If it didn't fail for PHP 5.1
then what would be your answer other than upgrade to 5.1, bug closed
when that's not an option right now for us?

I think I've done a 110% job of showing this test script fails under a
number of PHP 4.x releases and have spent the time to show it appears
to be the test script, not the actual passthru() function itself. 
Guess this is why this script has been broken for so long.  So much for
PHP 4.4 being an official release and for working towards making PHP
4.4.1 something that will build and test correctly on most systems.

At least this report will be out there for someone else to find; I've
already been contacted by someone with the same problem.  I can't put
any more time into this and if you guys aren't willing to have a QA
person take a look at this script, oh well.  Thanks for the help, I
guess and it can stay broken.  Cheers, Rob


Previous Comments:


[2005-08-12 11:13:17] [EMAIL PROTECTED]

Yes, you can convince me if you can test if that happens with the
latest PHP 5.1 snapshot..




[2005-08-12 04:50:07] RVaughn at pheedo dot com

Here's output from the straight-forward 'make test'.  I don't know how
many other bits of info I can send to convince someone that this test
script doesn't work right?  It fails the same no matter which way I run
it, and on three different version of PHP 4.x all on RHEL 3.0 servers. 
Is there any way I can convince someone this script has a problem?

=
TIME END 2005-08-11 19:26:29
=
TEST RESULT SUMMARY
-
Exts skipped:   55
Exts tested :   32
-
Number of tests :  630
Tests skipped   :  137 (21.7%)
Tests warned:0 (0.0%)
Tests failed:5 (0.8%)
Tests passed:  488 (77.5%)
-
Time taken  :   72 seconds
=

=
FAILED TEST SUMMARY
-
mb_send_mail() test 5 (lang=Simplified Chinese)
[ext/mbstring/tests/mb_send_mail05.phpt]
mb_send_mail() test 6 (lang=Traditional Chinese)
[ext/mbstring/tests/mb_send_mail06.phpt]
mb_send_mail() test 7 (lang=Korean)
[ext/mbstring/tests/mb_send_mail07.phpt]
[EMAIL PROTECTED] #16242 [ext/mbstring/tests/php_gr_jp_16242.phpt]
Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]
=



[2005-08-12 02:56:31] RVaughn at pheedo dot com

I ran the test exactly the way [EMAIL PROTECTED] said to in this bug
report.  If I run 'make test' the same thing happens.  I'll run it yet
again the Nth way you've asked.  Here you go, fails exactly the same
way:

# make test TESTS=ext/standard/tests/file/bug22414.phpt

=
CWD : /usr/local/src/Tars/php-4.4.0
PHP : /usr/local/src/Tars/php-4.4.0/sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 4.4.0
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP
Tue May 17 17:52:23 EDT 2005 i686
INI actual  : /etc/php.ini
More .INIs  : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini
Extra dirs  : 
=
Running selected tests.
FAIL Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]



[2005-08-12 02:22:01] [EMAIL PROTECTED]

You're running the test wrong. Use 'make test' or 'make test
TESTS=pathtotestsyouwanttorun'.

Secondly: I

#34111 [NEW]: Several tests w/string and zlib-based functions fail w/Japanese mbstring

[RVaughn at pheedo dot com]

From: RVaughn at pheedo dot com
Operating system: RHEL 3.0
PHP version:  4.4.0
PHP Bug Type: mbstring related
Bug description:  Several tests w/string and zlib-based functions fail 
w/Japanese mbstring

Description:

With PHP 4.4 on Red Hat Enterprise 3.0, several string and zlib-based
function calls fail when the 'mbstring' extension is activated, but work
when it is turned off.  These are shown in the test suites, which produce
a set of failures when the 'mbstring.encoding' parameter is set to
Japanese in the /etc/php.ini file, but when it is changed to English
or Neutral, the test suite returns different results, with none of the
string or zlib functions failing, but an XML-related routine failing
instead.

My guess is that the 'mbstring' stuff is either broken or does not fully
support all the possible character  string-related functions or does not
overload them properly.

My configuration for the build:

./configure 2configure.err '--host=i386-redhat-linux'
'--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu'
'--cache-file=../config.cache' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2' '--with-db4=/usr'
'--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd'
'--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses'
'--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl'
'--with-png' '--with-aspell' '--with-regex=system' '--with-xml'
'--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr'
'--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr'
'--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif'
'--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-discard-path' '--enable-track-vars' '--enable-trans-sid'
'--disable-yp' '--enable-wddx' '--without-oci8'
'--with-pear=/usr/share/pear' '--with-mysql=shared,/usr'
'--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack'
'--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath'
'--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio'
'--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans'
'--enable-mbregex' '--without-ldap' '--without-imap' '--without-imap-ssl'
'--without-kerberos' '--enable-mhash' '--with-apxs2=/usr/sbin/apxs' 

Reproduce code:
---
Build PHP 4.4 on an RHEL 3.0 system with the 'mbstring' extension turned
on.  In the '/etc/php.ini' file set the line 'mbstring.encoding =
Japanese' and you will get all the test failures outlined below.  Change
it back to 'Neutral' or 'English' and the failures go away.  The following
test scripts fail in Japanese setting:

ext/exif/tests/exif002.phpt
ext/standard/tests/strings/count_chars.phpt
ext/standard/tests/strings/strtoupper.phpt
ext/zlib/tests/001.phpt
ext/zlib/tests/002.phpt
ext/zlib/tests/003.phpt

Expected result:

This is the output of the 'make test' run if 'mbstring.encoding' is set to
Neutral or English in the /etc/php.ini file:

=
FAILED TEST SUMMARY
-
Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]
xml_parse_into_struct/umlauts in tags [ext/xml/tests/xml007.phpt]
=


Actual result:
--
This is the output of the 'make test' run if 'mbstring.encoding' is set to
Japanese in the /etc/php.ini file.  Nothing has been changed except that
single setting in the php.ini file:

=
FAILED TEST SUMMARY
-
Check for exif_thumbnail [ext/exif/tests/exif002.phpt]
Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]
count_chars() function [ext/standard/tests/strings/count_chars.phpt]
Test strtoupper on non-ASCII characters
[ext/standard/tests/strings/strtoupper.phpt]
gzdeflate()/gzinflate() [ext/zlib/tests/001.phpt]
gzcompress()/gzuncompress() [ext/zlib/tests/002.phpt]
gzencode()/base64_encode() [ext/zlib/tests/003.phpt]
=


-- 
Edit bug report at http://bugs.php.net/?id=34111edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=34111r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=34111r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=34111r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34111r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34111r=alreadyfixed
Need backtrace

#34075 [Fbk-Opn]: The ext/standard/tests/file/bug22414.phpt script fails

[RVaughn at pheedo dot com]

 ID:   34075
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

Shell is RHEL 3.0 /bin/bash.

# echo $TEST_PHP_EXECUTABLE
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

# ls -al `echo $TEST_PHP_EXECUTABLE`
-rwxr-xr-x1 root root  6254005 Aug 10 21:50
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

From the Makefile:

TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH)

top_builddir = /usr/src/redhat/SOURCES/php-4.3.8

SAPI_CLI_PATH = sapi/cli/php

The Makefile matches this, which is where the unstriped executable is:

# echo $TEST_PHP_EXECUTABLE
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

As per Tony's suggestion (thanks, but doesn't work, sorry I forgot that
I also tried 'run-tests.php'):

# TEST_PHP_EXECUTABLE=./sapi/cli/php  ./sapi/cli/php run-tests.php
ext/standard/tests/file/bug22414.phpt

=
CWD : /usr/src/redhat/SOURCES/php-4.3.8
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 4.3.8
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP
Tue May 17 17:52:23 EDT 2005 i686
INI actual  : /etc/php.ini
More .INIs  : /etc/php.d/imap.ini,/etc/php.d/ldap.ini
Extra dirs  : 
=
Running selected tests.
FAIL Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]

Output from this run is the same:

# more ext/standard/tests/file/bug22414.out
HELLO
Does not work

I haven't tried the CVS snapshot because we've given up on getting PHP
4.4 to build and work on RHEL 3.0 for now.  The fact that this test
fails on three different RHEL 3.0 servers w/three different PHP
versions (4.3.8, 4.3.11, 4.4) is what makes me think there's a problem
with this script on RHEL 3.0.  The test script is the same in all three
distributions, and it fails in the same way on all three, and I've
written some simple passthru() tests myself and the function seems to
work just fine, it's the test script.

Could be that passthru() is failing on RHEL 3.0 for all these versions
as my own tests are pretty simple.  Thanks!


Previous Comments:


[2005-08-11 11:24:51] [EMAIL PROTECTED]

./sapi/cli/php ext/standard/tests/file/bug22414.phpt

Ugh..Don't do it, please. These tests should not be run directly.
You must use run-tests.php for running them.

Please try to this:
TEST_PHP_EXECUTABLE=./sapi/cli/php  ./sapi/cli/php run-tests.php
ext/standard/tests/file/bug22414.phpt



[2005-08-11 11:22:30] [EMAIL PROTECTED]

The problem is with TEST_PHP_EXECUTABLE environment variable being set
to something wrong? Are you setting it yourself?
What shell are you using? What is it set to in Makefile ?
Have you tried latest CVS snapshot?






[2005-08-11 01:41:40] RVaughn at pheedo dot com

I have run this test with 'make test' as part of the whole suite, and
also directly with:

# ./sapi/cli/php -c /etc/php.ini ext/standard/tests/file/bug22414.phpt

and

# ./sapi/cli/php ext/standard/tests/file/bug22414.phpt

Fails in all three cases for PHP 4.4, 4.3.11, and 4.3.8.
The first test works, the second one which uses md5_file() to create a
hash over the php executable itself, fails with the errors I reported. 
I suspect it's something particular to RHEL 3.0 but have not had a
chance to test on a Fedora Core 2 system yet.



[2005-08-10 23:34:21] [EMAIL PROTECTED]

How do you run this test?




[2005-08-10 23:22:20] RVaughn at pheedo dot com

Description:

The ext/standard/tests/file/bug22414.phpt script in the test suite
always fails on Red Hat Enterprise 3.0.

I didn't report this originally as I thought it was a configuration or
installation problem with our system when working on PHP 4.4 but I'm
trying to run it under PHP 4.3.8 and 4.3.11 and it also fails in the
same manner, which leads me to believe it's either got a bug or isn't
written correctly to work on RHEL 3.0.

I've read Bug #22582: Problem with bug22414.phpt and while those
changes are incorporated they do not address the problem on RHEL 3.0. 
Other bug reports also do not address the problem.  I tried making a
link from /usr/local/php/bin/php to the new executable but that didn't
solve the problem.



Reproduce code:
---
Please see the ext/standard/tests/file/bug22414.phpt from the PHP 4.4,
4.3.8, or 4.3.11 distributions, it fails on all three.


Expected result

#34075 [Opn]: The ext/standard/tests/file/bug22414.phpt script fails

[RVaughn at pheedo dot com]

 ID:   34075
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
 Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

More info:

===
BUILD ENVIRONMENT
===
OS:
Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17
17:52:23 EDT \
2005 i686

Automake:
automake (GNU automake) 1.6.3
Written by Tom Tromey [EMAIL PROTECTED].

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Autoconf:
autoconf (GNU Autoconf) 2.57
Written by David J. MacKenzie and Akim Demaille.


Previous Comments:


[2005-08-11 19:06:18] RVaughn at pheedo dot com

Shell is RHEL 3.0 /bin/bash.

# echo $TEST_PHP_EXECUTABLE
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

# ls -al `echo $TEST_PHP_EXECUTABLE`
-rwxr-xr-x1 root root  6254005 Aug 10 21:50
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

From the Makefile:

TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH)

top_builddir = /usr/src/redhat/SOURCES/php-4.3.8

SAPI_CLI_PATH = sapi/cli/php

The Makefile matches this, which is where the unstriped executable is:

# echo $TEST_PHP_EXECUTABLE
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

As per Tony's suggestion (thanks, but doesn't work, sorry I forgot that
I also tried 'run-tests.php'):

# TEST_PHP_EXECUTABLE=./sapi/cli/php  ./sapi/cli/php run-tests.php
ext/standard/tests/file/bug22414.phpt

=
CWD : /usr/src/redhat/SOURCES/php-4.3.8
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 4.3.8
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP
Tue May 17 17:52:23 EDT 2005 i686
INI actual  : /etc/php.ini
More .INIs  : /etc/php.d/imap.ini,/etc/php.d/ldap.ini
Extra dirs  : 
=
Running selected tests.
FAIL Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]

Output from this run is the same:

# more ext/standard/tests/file/bug22414.out
HELLO
Does not work

I haven't tried the CVS snapshot because we've given up on getting PHP
4.4 to build and work on RHEL 3.0 for now.  The fact that this test
fails on three different RHEL 3.0 servers w/three different PHP
versions (4.3.8, 4.3.11, 4.4) is what makes me think there's a problem
with this script on RHEL 3.0.  The test script is the same in all three
distributions, and it fails in the same way on all three, and I've
written some simple passthru() tests myself and the function seems to
work just fine, it's the test script.

Could be that passthru() is failing on RHEL 3.0 for all these versions
as my own tests are pretty simple.  Thanks!



[2005-08-11 11:24:51] [EMAIL PROTECTED]

./sapi/cli/php ext/standard/tests/file/bug22414.phpt

Ugh..Don't do it, please. These tests should not be run directly.
You must use run-tests.php for running them.

Please try to this:
TEST_PHP_EXECUTABLE=./sapi/cli/php  ./sapi/cli/php run-tests.php
ext/standard/tests/file/bug22414.phpt



[2005-08-11 11:22:30] [EMAIL PROTECTED]

The problem is with TEST_PHP_EXECUTABLE environment variable being set
to something wrong? Are you setting it yourself?
What shell are you using? What is it set to in Makefile ?
Have you tried latest CVS snapshot?






[2005-08-11 01:41:40] RVaughn at pheedo dot com

I have run this test with 'make test' as part of the whole suite, and
also directly with:

# ./sapi/cli/php -c /etc/php.ini ext/standard/tests/file/bug22414.phpt

and

# ./sapi/cli/php ext/standard/tests/file/bug22414.phpt

Fails in all three cases for PHP 4.4, 4.3.11, and 4.3.8.
The first test works, the second one which uses md5_file() to create a
hash over the php executable itself, fails with the errors I reported. 
I suspect it's something particular to RHEL 3.0 but have not had a
chance to test on a Fedora Core 2 system yet.



[2005-08-10 23:34:21] [EMAIL PROTECTED]

How do you run this test?




The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/34075

-- 
Edit this bug report at http://bugs.php.net/?id=34075edit=1

#34075 [Fbk-Opn]: The ext/standard/tests/file/bug22414.phpt script fails

[RVaughn at pheedo dot com]

 ID:   34075
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
-Status:   Feedback
+Status:   Open
 Bug Type: *General Issues
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

Hi Sniper,

Sorry about that, here's the run on PHP 4.4 vs. PHP 4.3.8, the failure
and output are the same, note this is a different host name, the one
where I'm trying to build PHP 4.4.  If you need any more info please
let me know.  This is from the PHP 4.4 sources pulled on 1 Aug 2005:

# TEST_PHP_EXECUTABLE=./sapi/cli/php  ./sapi/cli/php run-tests.php
ext/standard/tests/file/bug22414.phpt

=
CWD : /usr/local/src/Tars/php-4.4.0
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 4.4.0
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP
Tue May 17 17:52:23 EDT 2005 i686
INI actual  : /etc/php.ini
More .INIs  : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini
Extra dirs  : 
=
Running selected tests.
FAIL Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]


Previous Comments:


[2005-08-11 23:06:51] [EMAIL PROTECTED]

All your output here shows version 4.3.8. Please do the tests REALLY
with PHP 4.4.0 or rather with the latest CVS snapshot of PHP 5.1
(http://snaps.php.net/php5-latest.tar.gz)




[2005-08-11 20:43:33] RVaughn at pheedo dot com

More info:

===
BUILD ENVIRONMENT
===
OS:
Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17
17:52:23 EDT \
2005 i686

Automake:
automake (GNU automake) 1.6.3
Written by Tom Tromey [EMAIL PROTECTED].

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Autoconf:
autoconf (GNU Autoconf) 2.57
Written by David J. MacKenzie and Akim Demaille.



[2005-08-11 19:06:18] RVaughn at pheedo dot com

Shell is RHEL 3.0 /bin/bash.

# echo $TEST_PHP_EXECUTABLE
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

# ls -al `echo $TEST_PHP_EXECUTABLE`
-rwxr-xr-x1 root root  6254005 Aug 10 21:50
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

From the Makefile:

TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH)

top_builddir = /usr/src/redhat/SOURCES/php-4.3.8

SAPI_CLI_PATH = sapi/cli/php

The Makefile matches this, which is where the unstriped executable is:

# echo $TEST_PHP_EXECUTABLE
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

As per Tony's suggestion (thanks, but doesn't work, sorry I forgot that
I also tried 'run-tests.php'):

# TEST_PHP_EXECUTABLE=./sapi/cli/php  ./sapi/cli/php run-tests.php
ext/standard/tests/file/bug22414.phpt

=
CWD : /usr/src/redhat/SOURCES/php-4.3.8
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 4.3.8
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP
Tue May 17 17:52:23 EDT 2005 i686
INI actual  : /etc/php.ini
More .INIs  : /etc/php.d/imap.ini,/etc/php.d/ldap.ini
Extra dirs  : 
=
Running selected tests.
FAIL Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]

Output from this run is the same:

# more ext/standard/tests/file/bug22414.out
HELLO
Does not work

I haven't tried the CVS snapshot because we've given up on getting PHP
4.4 to build and work on RHEL 3.0 for now.  The fact that this test
fails on three different RHEL 3.0 servers w/three different PHP
versions (4.3.8, 4.3.11, 4.4) is what makes me think there's a problem
with this script on RHEL 3.0.  The test script is the same in all three
distributions, and it fails in the same way on all three, and I've
written some simple passthru() tests myself and the function seems to
work just fine, it's the test script.

Could be that passthru() is failing on RHEL 3.0 for all these versions
as my own tests are pretty simple.  Thanks!



[2005-08-11 11:24:51] [EMAIL PROTECTED]

./sapi/cli/php ext/standard/tests/file/bug22414.phpt

Ugh..Don't do it, please. These tests should not be run directly.
You must use run-tests.php for running them.

Please try to this:
TEST_PHP_EXECUTABLE=./sapi/cli/php  ./sapi/cli/php run-tests.php
ext/standard/tests/file/bug22414.phpt

#34075 [Opn]: The ext/standard/tests/file/bug22414.phpt script fails

[RVaughn at pheedo dot com]

 ID:   34075
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
 Status:   Open
 Bug Type: *General Issues
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

Can't run these tests against PHP 5.1 - we are running PHP 4.3.2 on our
servers and want to upgrade to PHP 4.4 if possible but do not want to
move to PHP 5.1 yet, our application will require a lot of testing with
PHP 5 before we make that migration.  Our goal right now is simply to
get to PHP 4.4 for the bug and security fixes and to test our
application against it as well as upgrade MySQL from 3.x to 4.1-1, and
then migrate to PHP 5.x at some later date.  Thanks, Rob


Previous Comments:


[2005-08-12 02:08:36] RVaughn at pheedo dot com

Hi Sniper,

Sorry about that, here's the run on PHP 4.4 vs. PHP 4.3.8, the failure
and output are the same, note this is a different host name, the one
where I'm trying to build PHP 4.4.  If you need any more info please
let me know.  This is from the PHP 4.4 sources pulled on 1 Aug 2005:

# TEST_PHP_EXECUTABLE=./sapi/cli/php  ./sapi/cli/php run-tests.php
ext/standard/tests/file/bug22414.phpt

=
CWD : /usr/local/src/Tars/php-4.4.0
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 4.4.0
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP
Tue May 17 17:52:23 EDT 2005 i686
INI actual  : /etc/php.ini
More .INIs  : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini
Extra dirs  : 
=
Running selected tests.
FAIL Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]



[2005-08-11 23:06:51] [EMAIL PROTECTED]

All your output here shows version 4.3.8. Please do the tests REALLY
with PHP 4.4.0 or rather with the latest CVS snapshot of PHP 5.1
(http://snaps.php.net/php5-latest.tar.gz)




[2005-08-11 20:43:33] RVaughn at pheedo dot com

More info:

===
BUILD ENVIRONMENT
===
OS:
Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17
17:52:23 EDT \
2005 i686

Automake:
automake (GNU automake) 1.6.3
Written by Tom Tromey [EMAIL PROTECTED].

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Autoconf:
autoconf (GNU Autoconf) 2.57
Written by David J. MacKenzie and Akim Demaille.



[2005-08-11 19:06:18] RVaughn at pheedo dot com

Shell is RHEL 3.0 /bin/bash.

# echo $TEST_PHP_EXECUTABLE
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

# ls -al `echo $TEST_PHP_EXECUTABLE`
-rwxr-xr-x1 root root  6254005 Aug 10 21:50
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

From the Makefile:

TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH)

top_builddir = /usr/src/redhat/SOURCES/php-4.3.8

SAPI_CLI_PATH = sapi/cli/php

The Makefile matches this, which is where the unstriped executable is:

# echo $TEST_PHP_EXECUTABLE
/usr/src/redhat/SOURCES/php-4.3.8/sapi/cli/php

As per Tony's suggestion (thanks, but doesn't work, sorry I forgot that
I also tried 'run-tests.php'):

# TEST_PHP_EXECUTABLE=./sapi/cli/php  ./sapi/cli/php run-tests.php
ext/standard/tests/file/bug22414.phpt

=
CWD : /usr/src/redhat/SOURCES/php-4.3.8
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 4.3.8
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP
Tue May 17 17:52:23 EDT 2005 i686
INI actual  : /etc/php.ini
More .INIs  : /etc/php.d/imap.ini,/etc/php.d/ldap.ini
Extra dirs  : 
=
Running selected tests.
FAIL Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]

Output from this run is the same:

# more ext/standard/tests/file/bug22414.out
HELLO
Does not work

I haven't tried the CVS snapshot because we've given up on getting PHP
4.4 to build and work on RHEL 3.0 for now.  The fact that this test
fails on three different RHEL 3.0 servers w/three different PHP
versions (4.3.8, 4.3.11, 4.4) is what makes me think there's a problem
with this script on RHEL 3.0.  The test script is the same in all three
distributions, and it fails in the same way on all three, and I've
written some simple passthru() tests myself and the function seems to
work just

#34075 [Bgs]: The ext/standard/tests/file/bug22414.phpt script fails

[RVaughn at pheedo dot com]

 ID:   34075
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
 Status:   Bogus
 Bug Type: *General Issues
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

I ran the test exactly the way [EMAIL PROTECTED] said to in this bug
report.  If I run 'make test' the same thing happens.  I'll run it yet
again the Nth way you've asked.  Here you go, fails exactly the same
way:

# make test TESTS=ext/standard/tests/file/bug22414.phpt

=
CWD : /usr/local/src/Tars/php-4.4.0
PHP : /usr/local/src/Tars/php-4.4.0/sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 4.4.0
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP
Tue May 17 17:52:23 EDT 2005 i686
INI actual  : /etc/php.ini
More .INIs  : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini
Extra dirs  : 
=
Running selected tests.
FAIL Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]


Previous Comments:


[2005-08-12 02:22:01] [EMAIL PROTECTED]

You're running the test wrong. Use 'make test' or 'make test
TESTS=pathtotestsyouwanttorun'.

Secondly: I wasn't saying you need to move to PHP 5.1, I simply asked
you to TEST if this happens with it..




[2005-08-12 02:11:01] RVaughn at pheedo dot com

Can't run these tests against PHP 5.1 - we are running PHP 4.3.2 on our
servers and want to upgrade to PHP 4.4 if possible but do not want to
move to PHP 5.1 yet, our application will require a lot of testing with
PHP 5 before we make that migration.  Our goal right now is simply to
get to PHP 4.4 for the bug and security fixes and to test our
application against it as well as upgrade MySQL from 3.x to 4.1-1, and
then migrate to PHP 5.x at some later date.  Thanks, Rob



[2005-08-12 02:08:36] RVaughn at pheedo dot com

Hi Sniper,

Sorry about that, here's the run on PHP 4.4 vs. PHP 4.3.8, the failure
and output are the same, note this is a different host name, the one
where I'm trying to build PHP 4.4.  If you need any more info please
let me know.  This is from the PHP 4.4 sources pulled on 1 Aug 2005:

# TEST_PHP_EXECUTABLE=./sapi/cli/php  ./sapi/cli/php run-tests.php
ext/standard/tests/file/bug22414.phpt

=
CWD : /usr/local/src/Tars/php-4.4.0
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 4.4.0
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP
Tue May 17 17:52:23 EDT 2005 i686
INI actual  : /etc/php.ini
More .INIs  : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini
Extra dirs  : 
=
Running selected tests.
FAIL Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]



[2005-08-11 23:06:51] [EMAIL PROTECTED]

All your output here shows version 4.3.8. Please do the tests REALLY
with PHP 4.4.0 or rather with the latest CVS snapshot of PHP 5.1
(http://snaps.php.net/php5-latest.tar.gz)




[2005-08-11 20:43:33] RVaughn at pheedo dot com

More info:

===
BUILD ENVIRONMENT
===
OS:
Linux - Linux db.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP Tue May 17
17:52:23 EDT \
2005 i686

Automake:
automake (GNU automake) 1.6.3
Written by Tom Tromey [EMAIL PROTECTED].

Copyright 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

Autoconf:
autoconf (GNU Autoconf) 2.57
Written by David J. MacKenzie and Akim Demaille.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/34075

-- 
Edit this bug report at http://bugs.php.net/?id=34075edit=1

#34075 [Bgs-Opn]: The ext/standard/tests/file/bug22414.phpt script fails

[RVaughn at pheedo dot com]

 ID:   34075
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
-Status:   Bogus
+Status:   Open
 Bug Type: *General Issues
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

Here's output from the straight-forward 'make test'.  I don't know how
many other bits of info I can send to convince someone that this test
script doesn't work right?  It fails the same no matter which way I run
it, and on three different version of PHP 4.x all on RHEL 3.0 servers. 
Is there any way I can convince someone this script has a problem?

=
TIME END 2005-08-11 19:26:29
=
TEST RESULT SUMMARY
-
Exts skipped:   55
Exts tested :   32
-
Number of tests :  630
Tests skipped   :  137 (21.7%)
Tests warned:0 (0.0%)
Tests failed:5 (0.8%)
Tests passed:  488 (77.5%)
-
Time taken  :   72 seconds
=

=
FAILED TEST SUMMARY
-
mb_send_mail() test 5 (lang=Simplified Chinese)
[ext/mbstring/tests/mb_send_mail05.phpt]
mb_send_mail() test 6 (lang=Traditional Chinese)
[ext/mbstring/tests/mb_send_mail06.phpt]
mb_send_mail() test 7 (lang=Korean)
[ext/mbstring/tests/mb_send_mail07.phpt]
[EMAIL PROTECTED] #16242 [ext/mbstring/tests/php_gr_jp_16242.phpt]
Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]
=


Previous Comments:


[2005-08-12 02:56:31] RVaughn at pheedo dot com

I ran the test exactly the way [EMAIL PROTECTED] said to in this bug
report.  If I run 'make test' the same thing happens.  I'll run it yet
again the Nth way you've asked.  Here you go, fails exactly the same
way:

# make test TESTS=ext/standard/tests/file/bug22414.phpt

=
CWD : /usr/local/src/Tars/php-4.4.0
PHP : /usr/local/src/Tars/php-4.4.0/sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 4.4.0
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP
Tue May 17 17:52:23 EDT 2005 i686
INI actual  : /etc/php.ini
More .INIs  : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini
Extra dirs  : 
=
Running selected tests.
FAIL Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]



[2005-08-12 02:22:01] [EMAIL PROTECTED]

You're running the test wrong. Use 'make test' or 'make test
TESTS=pathtotestsyouwanttorun'.

Secondly: I wasn't saying you need to move to PHP 5.1, I simply asked
you to TEST if this happens with it..




[2005-08-12 02:11:01] RVaughn at pheedo dot com

Can't run these tests against PHP 5.1 - we are running PHP 4.3.2 on our
servers and want to upgrade to PHP 4.4 if possible but do not want to
move to PHP 5.1 yet, our application will require a lot of testing with
PHP 5 before we make that migration.  Our goal right now is simply to
get to PHP 4.4 for the bug and security fixes and to test our
application against it as well as upgrade MySQL from 3.x to 4.1-1, and
then migrate to PHP 5.x at some later date.  Thanks, Rob



[2005-08-12 02:08:36] RVaughn at pheedo dot com

Hi Sniper,

Sorry about that, here's the run on PHP 4.4 vs. PHP 4.3.8, the failure
and output are the same, note this is a different host name, the one
where I'm trying to build PHP 4.4.  If you need any more info please
let me know.  This is from the PHP 4.4 sources pulled on 1 Aug 2005:

# TEST_PHP_EXECUTABLE=./sapi/cli/php  ./sapi/cli/php run-tests.php
ext/standard/tests/file/bug22414.phpt

=
CWD : /usr/local/src/Tars/php-4.4.0
PHP : ./sapi/cli/php 
PHP_SAPI: cli
PHP_VERSION : 4.4.0
ZEND_VERSION: 1.3.0
PHP_OS  : Linux - Linux dev.pheedo.com 2.4.21-32.0.1.ELsmp #1 SMP
Tue May 17 17:52:23 EDT 2005 i686
INI actual  : /etc/php.ini
More .INIs  : /etc/php.d/mhash.ini,/etc/php.d/mysql.ini
Extra dirs  : 
=
Running selected tests.
FAIL Bug #22414: passthru() does not read data correctly
[ext

#34075 [NEW]: The ext/standard/tests/file/bug22414.phpt script fails

[RVaughn at pheedo dot com]

From: RVaughn at pheedo dot com
Operating system: RHEL 3.0
PHP version:  4.4.0
PHP Bug Type: Unknown/Other Function
Bug description:  The ext/standard/tests/file/bug22414.phpt script fails

Description:

The ext/standard/tests/file/bug22414.phpt script in the test suite always
fails on Red Hat Enterprise 3.0.

I didn't report this originally as I thought it was a configuration or
installation problem with our system when working on PHP 4.4 but I'm
trying to run it under PHP 4.3.8 and 4.3.11 and it also fails in the same
manner, which leads me to believe it's either got a bug or isn't written
correctly to work on RHEL 3.0.

I've read Bug #22582: Problem with bug22414.phpt and while those changes
are incorporated they do not address the problem on RHEL 3.0.  Other bug
reports also do not address the problem.  I tried making a link from
/usr/local/php/bin/php to the new executable but that didn't solve the
problem.



Reproduce code:
---
Please see the ext/standard/tests/file/bug22414.phpt from the PHP 4.4,
4.3.8, or 4.3.11 distributions, it fails on all three.


Expected result:

 EXPECTED OUTPUT
HELLO
Works


Actual result:
--
 ACTUAL OUTPUT
HELLO
sh: line 1: /usr/local/php/bin/php: No such file or directory
Does not work

This fails exactly this way under PHP 4.3.8, 4.3.11 and 4.4 on RHEL 3.0
which is why I believe it's a bug with the script.  The script is
identical in all three PHP source code distributions.

I tried to fix the problem by copying the new php executable 

# mkdir -p /usr/local/php/bin
# cp sapi/cli/php /usr/local/php/bin/php

This causes this error on RHEL 3.0 for PHP 4.4, 4.3.11 and 4.3.8:

--FILE--
sh: line 1: -n: command not found

sh: line 1: -n: command not found

Warning: md5_file(): Unable to open file in
/usr/src/redhat/SOURCES/php-4.3.8/ext/standard/tests/file/bug22414.phpt on
line 24
Does not work

Please don't yell at me, I'm just trying to report what I'm guessing is a
potential bug particular to RHEL 3.0 and have written my own passthru()
function tests which seem to work just fine.  Cheers, Rob V.

-- 
Edit bug report at http://bugs.php.net/?id=34075edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=34075r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=34075r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=34075r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34075r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34075r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=34075r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=34075r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=34075r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34075r=support
Expected behavior:   http://bugs.php.net/fix.php?id=34075r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=34075r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=34075r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34075r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=34075r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34075r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=34075r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34075r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=34075r=float
No Zend Extensions:  http://bugs.php.net/fix.php?id=34075r=nozend
MySQL Configuration Error:   http://bugs.php.net/fix.php?id=34075r=mysqlcfg

#34075 [Fbk-Opn]: The ext/standard/tests/file/bug22414.phpt script fails

[RVaughn at pheedo dot com]

 ID:   34075
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
-Status:   Feedback
+Status:   Open
 Bug Type: Unknown/Other Function
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

I have run this test with 'make test' as part of the whole suite, and
also directly with:

# ./sapi/cli/php -c /etc/php.ini ext/standard/tests/file/bug22414.phpt

and

# ./sapi/cli/php ext/standard/tests/file/bug22414.phpt

Fails in all three cases for PHP 4.4, 4.3.11, and 4.3.8.
The first test works, the second one which uses md5_file() to create a
hash over the php executable itself, fails with the errors I reported. 
I suspect it's something particular to RHEL 3.0 but have not had a
chance to test on a Fedora Core 2 system yet.


Previous Comments:


[2005-08-10 23:34:21] [EMAIL PROTECTED]

How do you run this test?




[2005-08-10 23:22:20] RVaughn at pheedo dot com

Description:

The ext/standard/tests/file/bug22414.phpt script in the test suite
always fails on Red Hat Enterprise 3.0.

I didn't report this originally as I thought it was a configuration or
installation problem with our system when working on PHP 4.4 but I'm
trying to run it under PHP 4.3.8 and 4.3.11 and it also fails in the
same manner, which leads me to believe it's either got a bug or isn't
written correctly to work on RHEL 3.0.

I've read Bug #22582: Problem with bug22414.phpt and while those
changes are incorporated they do not address the problem on RHEL 3.0. 
Other bug reports also do not address the problem.  I tried making a
link from /usr/local/php/bin/php to the new executable but that didn't
solve the problem.



Reproduce code:
---
Please see the ext/standard/tests/file/bug22414.phpt from the PHP 4.4,
4.3.8, or 4.3.11 distributions, it fails on all three.


Expected result:

 EXPECTED OUTPUT
HELLO
Works


Actual result:
--
 ACTUAL OUTPUT
HELLO
sh: line 1: /usr/local/php/bin/php: No such file or directory
Does not work

This fails exactly this way under PHP 4.3.8, 4.3.11 and 4.4 on RHEL 3.0
which is why I believe it's a bug with the script.  The script is
identical in all three PHP source code distributions.

I tried to fix the problem by copying the new php executable 

# mkdir -p /usr/local/php/bin
# cp sapi/cli/php /usr/local/php/bin/php

This causes this error on RHEL 3.0 for PHP 4.4, 4.3.11 and 4.3.8:

--FILE--
sh: line 1: -n: command not found

sh: line 1: -n: command not found

Warning: md5_file(): Unable to open file in
/usr/src/redhat/SOURCES/php-4.3.8/ext/standard/tests/file/bug22414.phpt
on line 24
Does not work

Please don't yell at me, I'm just trying to report what I'm guessing is
a potential bug particular to RHEL 3.0 and have written my own
passthru() function tests which seem to work just fine.  Cheers, Rob V.





-- 
Edit this bug report at http://bugs.php.net/?id=34075edit=1

#34041 [NEW]: md5() function fails

[RVaughn at pheedo dot com]

From: RVaughn at pheedo dot com
Operating system: RHEL 3.0
PHP version:  4.4.0
PHP Bug Type: mhash related
Bug description:  md5() function fails

Description:

The md5() function in the 'mhash' fails.  Several of the 'mhash' tests in
the PHP test suite fail on Red Hat Ent. 3.0 and two other tests that use
the md5() call also fail because of this call although the functions/bugs
they're testing are fine (as confirmed by hand.)

The mhash tests that fail:

mhash() test [ext/mhash/tests/001.phpt]
mhash_keygen_s2k() test [ext/mhash/tests/003.phpt]

The other test that fails due to md5() function usage:

[EMAIL PROTECTED] #16242 [ext/mbstring/tests/php_gr_jp_16242.phpt]
Bug #22414: passthru() does not read data correctly
[ext/standard/tests/file/bug22414.phpt]

We had mhash-0.9.1 and mhash-devel-0.9.1 installed, which I upgraded to
mhash-0.9.2-3 and mhash-devel-0.9.2-3 but this did not fix or change the
output.

My configuration:

./configure 2configure.err '--host=i386-redhat-linux'
'--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu'
'--cache-file=../config.cache' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2' '--with-db4=/usr'
'--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd'
'--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses'
'--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl'
'--with-png' '--with-aspell' '--with-regex=system' '--with-xml'
'--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr'
'--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr'
'--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif'
'--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-discard-path' '--enable-track-vars' '--enable-trans-sid'
'--disable-yp' '--enable-wddx' '--without-oci8'
'--with-pear=/usr/share/pear' '--with-kerberos' '--with-mysql=shared,/usr'
'--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack'
'--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath'
'--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio'
'--enable-mcal' '--enable-mbstring=/usr/lib/php4/'
'--enable-mbstr-enc-trans' '--enable-mbregex'
'--with-apxs2=/usr/sbin/apxs'


Reproduce code:
---
The following test scripts illustrate the failures completely on RHEL
3.0:

.../ext/mhash/tests/001.phpt
.../ext/mhash/tests/003.phpt

Failure caused by md5() call:

.../ext/mbstring/tests/php_gr_jp_16242.phpt

I have modified the ext/standard/tests/file/bug22414.phpt script to call
the crc32() function as well, which also fails.  You can retrieve a copy
at:

http://dev.pheedo.com/temp/bug22414.phpt

It does have debugging statements (echo calls) commented out.


Expected result:

===
/usr/local/src/Tars/php-4.4.0/ext/mhash/tests/001.phpt
===

 EXPECTED OUTPUT
MHASH_MD5
ok

MHASH_SHA1
ok

MHASH_HAVAL256
ok

MHASH_HAVAL192
ok

MHASH_HAVAL224
ok

MHASH_HAVAL160
ok

MHASH_RIPEMD160
ok

MHASH_GOST
ok

MHASH_TIGER
ok

MHASH_CRC32
ok

MHASH_CRC32B
ok


Actual result:
--
No output from either mhash test.

-- 
Edit bug report at http://bugs.php.net/?id=34041edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=34041r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=34041r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=34041r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34041r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34041r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=34041r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=34041r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=34041r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=34041r=support
Expected behavior:   http://bugs.php.net/fix.php?id=34041r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=34041r=notenoughinfo
Submitted twice: 
http://bugs.php.net/fix.php?id=34041r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=34041r=globals
PHP 3 support discontinued:  http://bugs.php.net/fix.php?id=34041r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=34041r=dst
IIS Stability:   http://bugs.php.net/fix.php?id=34041r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=34041r=gnused
Floating point limitations:  http://bugs.php.net/fix.php?id=34041r=float
No Zend Extensions:  http://bugs.php.net

#33997 [Fbk-Opn]: Returned: Bug #16069 - ICONV transliteration failure

[RVaughn at pheedo dot com]

 ID:   33997
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
-Status:   Feedback
+Status:   Open
 Bug Type: ICONV related
 Operating System: Red Hat Ent. 3.0
 PHP Version:  5CVS, 4CVS (2005-08-04)
 New Comment:

The patch Sniper referred to:

http://www.php.net/~jani/patches/bug33997.patch

Does fix the bug properly and completely, we've tested it thoroughly,
so I won't close this bug but I do think you can roll that patch
forward into 4.4.1 as a fix and close this once that's done?

Please let me know if there's anything else I can provide?  Do you
really need the .out and .exp if I can assure you the patch fixes the
bug?  Or do you want to see the results from the patched install? 
Thanks, Rob


Previous Comments:


[2005-08-07 14:42:23] [EMAIL PROTECTED]

Please provide a location where we can download your failed test's .out
and .exp file.



[2005-08-05 22:15:08] [EMAIL PROTECTED]

Well, the patch is not approved/applied to CVS yet so keep this report
open. We'll close this once the bug is really fixed.



[2005-08-05 01:18:33] RVaughn at pheedo dot com

Works perfectly!  Hopefully this patch can be rolled into PHP 4.4.1? 
This one can be closed, that was the fix.  Thanks much!  Cheers!



[2005-08-05 00:39:44] [EMAIL PROTECTED]

This seems to fix the problem:

http://www.php.net/~jani/patches/bug33997.patch

I now get the correct result which I also got with the command line
iconv tool.




[2005-08-04 23:34:18] RVaughn at pheedo dot com

Do let me know if you want me to put the output somewhere on our site
where it can be downloaded, the code itself is just the PHP-provided
test: bug16069.phpt.  Thanks!  Cheers!



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/33997

-- 
Edit this bug report at http://bugs.php.net/?id=33997edit=1

#34015 [NEW]: Test script php_gr_jp_16242.phpt mislocates libraries

[RVaughn at pheedo dot com]

From: RVaughn at pheedo dot com
Operating system: RHEL 3.0
PHP version:  4.4.0
PHP Bug Type: Unknown/Other Function
Bug description:  Test script php_gr_jp_16242.phpt mislocates libraries

Description:

The 'php_gr_jp_16242.phpt' test script does not look in the proper place
for PHP-required libraries, note they look in
'/usr/local/lib/php/20020429' (what the heck is that?) vs. the correct
spot: '/usr/lib/php4'.  Note that this is listed in the '/etc/php.ini'
file:

; UNIX: /path1:/path2
include_path = .:/php/includes:/usr/lib/php4:/usr/local/lib/php

Errors:

PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/imap.so' -
/usr/local/lib/php/20020429/imap.so: cannot open shared object file: No
such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/ldap.so' -
/usr/local/lib/php/20020429/ldap.so: cannot open shared object file: No
such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/mhash.so' -
/usr/local/lib/php/20020429/mhash.so: cannot open shared object file: No
such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/mysql.so' -
/usr/local/lib/php/20020429/mysql.so: cannot open shared object file: No
such file or directory in Unknown on line 0

This is on a Red Hat Enterprise 3.0 system with the following configure
settings:

./configure 2configure.err '--host=i386-redhat-linux'
'--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu'
'--cache-file=../config.cache' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2' '--with-db4=/usr'
'--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd'
'--enable-gd-native-ttf' '--without-gdbm' '--with-gettext' '--with-ncurses'
'--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl'
'--with-png' '--with-aspell' '--with-regex=system' '--with-xml'
'--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr'
'--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr'
'--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif'
'--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-discard-path' '--enable-track-vars' '--enable-trans-sid'
'--disable-yp' '--enable-wddx' '--without-oci8'
'--with-pear=/usr/share/pear' '--with-kerberos' '--with-mysql=shared,/usr'
'--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack'
'--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath'
'--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio'
'--enable-mcal' '--enable-mbstring=/usr/lib/php4/'
'--enable-mbstr-enc-trans' '--enable-mbregex'
'--with-apxs2=/usr/sbin/apxs' | tee configure.out

Reproduce code:
---
The test script .../ext/mbstring/tests/php_gr_jp_16242.phpt in the PHP 4.4
distro will reproduce this error on this platform.

Expected result:

The output of the code is correct except for these weird warnings:

[...warnings removed...]
string(8) Japanese
string(5) UTF-8
string(5) UTF-8


Actual result:
--
 EXPECTED OUTPUT
string(8) Japanese
string(5) UTF-8
string(5) UTF-8
 ACTUAL OUTPUT
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/200\
20429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open shared
object\
 file: No such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/200\
20429/ldap.so' - /usr/local/lib/php/20020429/ldap.so: cannot open shared
object\
 file: No such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/200\
20429/mhash.so' - /usr/local/lib/php/20020429/mhash.so: cannot open shared
obje\
ct file: No such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/200\
20429/mysql.so' - /usr/local/lib/php/20020429/mysql.so: cannot open shared
obje\
ct file: No such file or directory in Unknown on line 0
string(8) Japanese
string(5) UTF-8
string(5) UTF-8


-- 
Edit bug report at http://bugs.php.net/?id=34015edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=34015r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=34015r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=34015r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=34015r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=34015r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=34015r=needtrace
Need Reproduce Script

#34015 [Csd-Opn]: Test script php_gr_jp_16242.phpt mislocates libraries

[RVaughn at pheedo dot com]

 ID:   34015
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
-Status:   Closed
+Status:   Open
 Bug Type: mbstring related
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

As said, these do *not* appear in my php.ini file.  You're just making
an assumption about that.  The paths do *not* appear anywhere in the
php.ini (the tests are supposed to ignore the /etc/php.ini file and use
the one in the source code anyway, according to README.TESTING) and
those weird paths do not appear anywhere on my system nor in the source
code.  The conclusions you've jumped to are mistaken.  Thanks.


Previous Comments:


[2005-08-05 22:39:56] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2005-08-05 22:36:53] [EMAIL PROTECTED]

It does't look for any libraries (and this is obvius from its source).
Fix your system or remove these extensions from your php.ini
Not PHP problem.



[2005-08-05 22:23:31] RVaughn at pheedo dot com

Description:

The 'php_gr_jp_16242.phpt' test script does not look in the proper
place for PHP-required libraries, note they look in
'/usr/local/lib/php/20020429' (what the heck is that?) vs. the correct
spot: '/usr/lib/php4'.  Note that this is listed in the '/etc/php.ini'
file:

; UNIX: /path1:/path2
include_path = .:/php/includes:/usr/lib/php4:/usr/local/lib/php

Errors:

PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/imap.so' -
/usr/local/lib/php/20020429/imap.so: cannot open shared object file: No
such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/ldap.so' -
/usr/local/lib/php/20020429/ldap.so: cannot open shared object file: No
such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/mhash.so' -
/usr/local/lib/php/20020429/mhash.so: cannot open shared object file:
No such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/mysql.so' -
/usr/local/lib/php/20020429/mysql.so: cannot open shared object file:
No such file or directory in Unknown on line 0

This is on a Red Hat Enterprise 3.0 system with the following configure
settings:

./configure 2configure.err '--host=i386-redhat-linux'
'--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu'
'--cache-file=../config.cache' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2' '--with-db4=/usr'
'--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr'
'--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext'
'--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr'
'--with-openssl' '--with-png' '--with-aspell' '--with-regex=system'
'--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr'
'--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared'
'--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU'
'--enable-bcmath' '--enable-exif' '--enable-ftp'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path'
'--enable-track-vars' '--enable-trans-sid' '--disable-yp'
'--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear'
'--with-kerberos' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr'
'--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared'
'--enable-memory-limit' '--enable-bcmath' '--enable-shmop'
'--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal'
'--enable-mbstring=/usr/lib/php4/' '--enable-mbstr-enc-trans'
'--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' | tee configure.out

Reproduce code:
---
The test script .../ext/mbstring/tests/php_gr_jp_16242.phpt in the PHP
4.4 distro will reproduce this error on this platform.

Expected result:

The output of the code is correct except for these weird warnings:

[...warnings removed...]
string(8) Japanese
string(5) UTF-8
string(5) UTF-8


Actual result:
--
 EXPECTED OUTPUT
string(8) Japanese
string(5) UTF-8
string(5) UTF-8
 ACTUAL OUTPUT
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/200\
20429/imap.so' - /usr/local/lib/php/20020429/imap.so: cannot open
shared object\
 file: No such file or directory in Unknown on line 0
PHP Warning

#34015 [Csd-Opn]: Test script php_gr_jp_16242.phpt mislocates libraries

[RVaughn at pheedo dot com]

 ID:   34015
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
-Status:   Closed
+Status:   Open
 Bug Type: mbstring related
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

Thanks Sniper, for a real answer rather than a rote one.  Is there any
way to get more info on this bug?  Namely, is it a problem with the
test script or with PHP or both?  I don't want to have to pull a whole
new distribution of PHP 4.4 down and build it from scratch; we're
trying to run a business.  Thanks!  Cheers, Rob


Previous Comments:


[2005-08-06 00:41:59] [EMAIL PROTECTED]

Hehe..don't trust everything you read. :)
The tests definately use your php.ini. It's intentional and will not be
changed. 



[2005-08-06 00:39:22] RVaughn at pheedo dot com

As said, these do *not* appear in my php.ini file.  You're just making
an assumption about that.  The paths do *not* appear anywhere in the
php.ini (the tests are supposed to ignore the /etc/php.ini file and use
the one in the source code anyway, according to README.TESTING) and
those weird paths do not appear anywhere on my system nor in the source
code.  The conclusions you've jumped to are mistaken.  Thanks.



[2005-08-05 22:39:56] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2005-08-05 22:36:53] [EMAIL PROTECTED]

It does't look for any libraries (and this is obvius from its source).
Fix your system or remove these extensions from your php.ini
Not PHP problem.



[2005-08-05 22:23:31] RVaughn at pheedo dot com

Description:

The 'php_gr_jp_16242.phpt' test script does not look in the proper
place for PHP-required libraries, note they look in
'/usr/local/lib/php/20020429' (what the heck is that?) vs. the correct
spot: '/usr/lib/php4'.  Note that this is listed in the '/etc/php.ini'
file:

; UNIX: /path1:/path2
include_path = .:/php/includes:/usr/lib/php4:/usr/local/lib/php

Errors:

PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/imap.so' -
/usr/local/lib/php/20020429/imap.so: cannot open shared object file: No
such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/ldap.so' -
/usr/local/lib/php/20020429/ldap.so: cannot open shared object file: No
such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/mhash.so' -
/usr/local/lib/php/20020429/mhash.so: cannot open shared object file:
No such file or directory in Unknown on line 0
PHP Warning:  Unknown(): Unable to load dynamic library
'/usr/local/lib/php/20020429/mysql.so' -
/usr/local/lib/php/20020429/mysql.so: cannot open shared object file:
No such file or directory in Unknown on line 0

This is on a Red Hat Enterprise 3.0 system with the following configure
settings:

./configure 2configure.err '--host=i386-redhat-linux'
'--build=i386-redhat-linux' '--target=i386-redhat-linux-gnu'
'--cache-file=../config.cache' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2' '--with-db4=/usr'
'--with-curl' '--with-freetype-dir=/usr' '--with-png-dir=/usr'
'--with-gd' '--enable-gd-native-ttf' '--without-gdbm' '--with-gettext'
'--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr'
'--with-openssl' '--with-png' '--with-aspell' '--with-regex=system'
'--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr'
'--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared'
'--with-pcre-regex=/usr' '--with-zlib' '--with-layout=GNU'
'--enable-bcmath' '--enable-exif' '--enable-ftp'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path'
'--enable-track-vars' '--enable-trans-sid' '--disable-yp'
'--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear'
'--with-kerberos' '--with-mysql=shared,/usr' '--with-snmp=shared,/usr'
'--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared'
'--enable-memory-limit' '--enable-bcmath' '--enable-shmop'
'--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal'
'--enable-mbstring=/usr/lib/php4/' '--enable-mbstr-enc-trans'
'--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' | tee configure.out

#34015 [Opn]: Test script php_gr_jp_16242.phpt mislocates libraries

[RVaughn at pheedo dot com]

 ID:   34015
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
 Status:   Open
 Bug Type: mbstring related
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

Wait, what's intentional?  That the README file is misleading (or
wrong) in saying the system php.ini file is used?  Or that the system
ini file is used, which means the README file ought to be updated? 
Sorry, really confused now... thanks!
Cheers, Rob


Previous Comments:


[2005-08-06 00:44:28] RVaughn at pheedo dot com

Thanks Sniper, for a real answer rather than a rote one.  Is there any
way to get more info on this bug?  Namely, is it a problem with the
test script or with PHP or both?  I don't want to have to pull a whole
new distribution of PHP 4.4 down and build it from scratch; we're
trying to run a business.  Thanks!  Cheers, Rob



[2005-08-06 00:41:59] [EMAIL PROTECTED]

Hehe..don't trust everything you read. :)
The tests definately use your php.ini. It's intentional and will not be
changed. 



[2005-08-06 00:39:22] RVaughn at pheedo dot com

As said, these do *not* appear in my php.ini file.  You're just making
an assumption about that.  The paths do *not* appear anywhere in the
php.ini (the tests are supposed to ignore the /etc/php.ini file and use
the one in the source code anyway, according to README.TESTING) and
those weird paths do not appear anywhere on my system nor in the source
code.  The conclusions you've jumped to are mistaken.  Thanks.



[2005-08-05 22:39:56] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





[2005-08-05 22:36:53] [EMAIL PROTECTED]

It does't look for any libraries (and this is obvius from its source).
Fix your system or remove these extensions from your php.ini
Not PHP problem.



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/34015

-- 
Edit this bug report at http://bugs.php.net/?id=34015edit=1

#34015 [Opn]: Test script php_gr_jp_16242.phpt mislocates libraries

[RVaughn at pheedo dot com]

 ID:   34015
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
 Status:   Open
 Bug Type: mbstring related
 Operating System: RHEL 3.0
 PHP Version:  4.4.0
 New Comment:

Those bad paths do not appear in my /etc/php.ini system file.  In the
original report I show the include path:

; UNIX: /path1:/path2
include_path=.:/php/includes:/usr/lib/php4:/usr/local/lib/php

Why isn't the test script using that?  Thanks!


Previous Comments:


[2005-08-06 00:46:21] RVaughn at pheedo dot com

Wait, what's intentional?  That the README file is misleading (or
wrong) in saying the system php.ini file is used?  Or that the system
ini file is used, which means the README file ought to be updated? 
Sorry, really confused now... thanks!
Cheers, Rob



[2005-08-06 00:44:28] RVaughn at pheedo dot com

Thanks Sniper, for a real answer rather than a rote one.  Is there any
way to get more info on this bug?  Namely, is it a problem with the
test script or with PHP or both?  I don't want to have to pull a whole
new distribution of PHP 4.4 down and build it from scratch; we're
trying to run a business.  Thanks!  Cheers, Rob



[2005-08-06 00:41:59] [EMAIL PROTECTED]

Hehe..don't trust everything you read. :)
The tests definately use your php.ini. It's intentional and will not be
changed. 



[2005-08-06 00:39:22] RVaughn at pheedo dot com

As said, these do *not* appear in my php.ini file.  You're just making
an assumption about that.  The paths do *not* appear anywhere in the
php.ini (the tests are supposed to ignore the /etc/php.ini file and use
the one in the source code anyway, according to README.TESTING) and
those weird paths do not appear anywhere on my system nor in the source
code.  The conclusions you've jumped to are mistaken.  Thanks.



[2005-08-05 22:39:56] [EMAIL PROTECTED]

This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.





The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/34015

-- 
Edit this bug report at http://bugs.php.net/?id=34015edit=1

#33997 [NEW]: Returned: Bug #16069 - ICONV transliteration failure

[RVaughn at pheedo dot com]

From: RVaughn at pheedo dot com
Operating system: Red Hat Ent. 3.0
PHP version:  4.4.0
PHP Bug Type: ICONV related
Bug description:  Returned: Bug #16069 - ICONV transliteration failure

Description:

In the PHP 4.4 test suite, the test for closed bug #16069 fails:

FAIL Bug #16069 [ext/iconv/tests/bug16069.phpt]

Checked the output and it does diverge from the expected output in the
same way the old bug from 2002 did.  The 'iconv' libraries are up-to-date
on the system:

# up2date glibc-common
The following packages you requested are already updated:
glibc-common

# rpm -qi glibc-common
Name: glibc-common   Relocations: (not relocatable)
Version: 2.3.2   Vendor: Red Hat, Inc.
Release: 95.33   Build Date: Wed 23 Feb 2005

The bug16069.phpt script will reproduce this every time.  Configured with
the following settings:

./configure  '--host=i386-redhat-linux' '--build=i386-redhat-linux'
'--target=i386-redhat-linux-gnu' '--cache-file=../config.cache'
'--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d'
'--enable-force-cgi-redirect' '--disable-debug' '--enable-pic'
'--disable-rpath' '--enable-inline-optimization' '--with-bz2'
'--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr'
'--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf'
'--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp'
'--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png'
'--with-aspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr'
'--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr'
'--with-xmlrpc=shared' '--with-pcre-regex=/usr' '--with-zlib'
'--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp'
'--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path'
'--enable-track-vars' '--enable-trans-sid' '--disable-yp' '--enable-wddx'
'--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared'
'--with-imap-ssl' '--with-kerberos' '--with-ldap=shared'
'--with-mysql=shared,/usr' '--with-snmp=shared,/usr' '--with-snmp=shared'
'--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit'
'--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx'
'--enable-dio' '--enable-mcal' '--enable-mbstring'
'--enable-mbstr-enc-trans' '--enable-mbregex'
'--with-apxs2=/usr/sbin/apxs'

Using a standard /etc/php.ini file that works fine under PHP 4.3.6 which
we upgraded to several weeks ago and this bug does not appear to be a
problem with.

Got the following warning (the only one) when doing a 'make':

/usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c:
In function `convert':
/usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c:74:
warning: passing arg 2 of `iconv' from incompatible pointer type

Guessing that the call to updated versions of 'libxml' or 'libxml2' is the
problem, here's the versions for both:

# rpm -qi libxml
Name: libxml Relocations: (not relocatable)
Version: 1.8.17  Vendor: Red Hat, Inc.
Release: 9.2 Build Date: Wed 17 Nov 2004

# rpm -qi libxml2
Name: libxml2Relocations: /usr 
Version: 2.5.10  Vendor: Red Hat, Inc.
Release: 7   Build Date: Wed 27 Oct 2004


Reproduce code:
---
Please use .../ext/iconv/tests/bug16069.phpt in the test suite.

Expected result:

The output returned does not match expected results.

Actual result:
--
This bug *cannot* be safely ignored as per the Won't Fix status in Bug
#32367 because it is breaking our ability to use Japanese characters in
our application with the 'mbstring' libraries.  As long as we use English
it's fine, but it blows up our Japanese translations (via Smarty
templates.)  Please do not claim it can be ignored or is a Won't Fix as
multi-language support is becoming more and more necessary with PHP and
this bug is causing major problems with it.

-- 
Edit bug report at http://bugs.php.net/?id=33997edit=1
-- 
Try a CVS snapshot (php4):   http://bugs.php.net/fix.php?id=33997r=trysnapshot4
Try a CVS snapshot (php5.0): 
http://bugs.php.net/fix.php?id=33997r=trysnapshot50
Try a CVS snapshot (php5.1): 
http://bugs.php.net/fix.php?id=33997r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33997r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33997r=alreadyfixed
Need backtrace:  http://bugs.php.net/fix.php?id=33997r=needtrace
Need Reproduce Script:   http://bugs.php.net/fix.php?id=33997r=needscript
Try newer version:   http://bugs.php.net/fix.php?id=33997r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33997r=support
Expected behavior:   http://bugs.php.net/fix.php?id=33997r=notwrong
Not enough info: 
http://bugs.php.net/fix.php?id=33997r=notenoughinfo
Submitted twice: 
http

#33997 [Fbk-Opn]: Returned: Bug #16069 - ICONV transliteration failure

[RVaughn at pheedo dot com]

 ID:   33997
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
-Status:   Feedback
+Status:   Open
 Bug Type: ICONV related
 Operating System: Red Hat Ent. 3.0
 PHP Version:  4.4.0
 New Comment:

Was getting one warning in the 'make' output as reported, fixed the
code in:

.../php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c

and now do not get a warning in the 'make' but it did not fix the
problem, and multi-byte string output for Japanese text is being messed
up by this reopened? never-fixed? bug.

Here's the diff to fix the warning for encodings.c, very simple:

64c64
   char const *src_ptr = src;
---
   char* src_ptr = (char*) src;

It clearly states the iconv() parameters and you can't pass a 'const'
into the call, period.


Previous Comments:


[2005-08-04 20:25:57] [EMAIL PROTECTED]

How *exactly* does it fail?



[2005-08-04 20:23:24] RVaughn at pheedo dot com

Description:

In the PHP 4.4 test suite, the test for closed bug #16069 fails:

FAIL Bug #16069 [ext/iconv/tests/bug16069.phpt]

Checked the output and it does diverge from the expected output in the
same way the old bug from 2002 did.  The 'iconv' libraries are
up-to-date on the system:

# up2date glibc-common
The following packages you requested are already updated:
glibc-common

# rpm -qi glibc-common
Name: glibc-common   Relocations: (not relocatable)
Version: 2.3.2   Vendor: Red Hat, Inc.
Release: 95.33   Build Date: Wed 23 Feb 2005

The bug16069.phpt script will reproduce this every time.  Configured
with the following settings:

./configure  '--host=i386-redhat-linux' '--build=i386-redhat-linux'
'--target=i386-redhat-linux-gnu' '--cache-file=../config.cache'
'--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d'
'--enable-force-cgi-redirect' '--disable-debug' '--enable-pic'
'--disable-rpath' '--enable-inline-optimization' '--with-bz2'
'--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr'
'--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf'
'--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp'
'--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png'
'--with-aspell' '--with-regex=system' '--with-xml'
'--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr'
'--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr'
'--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif'
'--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-discard-path' '--enable-track-vars' '--enable-trans-sid'
'--disable-yp' '--enable-wddx' '--without-oci8'
'--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl'
'--with-kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr'
'--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack'
'--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath'
'--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio'
'--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans'
'--enable-mbregex' '--with-apxs2=/usr/sbin/apxs'

Using a standard /etc/php.ini file that works fine under PHP 4.3.6
which we upgraded to several weeks ago and this bug does not appear to
be a problem with.

Got the following warning (the only one) when doing a 'make':

/usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c:
In function `convert':
/usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c:74:
warning: passing arg 2 of `iconv' from incompatible pointer type

Guessing that the call to updated versions of 'libxml' or 'libxml2' is
the problem, here's the versions for both:

# rpm -qi libxml
Name: libxml Relocations: (not relocatable)
Version: 1.8.17  Vendor: Red Hat, Inc.
Release: 9.2 Build Date: Wed 17 Nov 2004

# rpm -qi libxml2
Name: libxml2Relocations: /usr 
Version: 2.5.10  Vendor: Red Hat, Inc.
Release: 7   Build Date: Wed 27 Oct 2004


Reproduce code:
---
Please use .../ext/iconv/tests/bug16069.phpt in the test suite.

Expected result:

The output returned does not match expected results.

Actual result:
--
This bug *cannot* be safely ignored as per the Won't Fix status in
Bug #32367 because it is breaking our ability to use Japanese
characters in our application with the 'mbstring' libraries.  As long
as we use English it's fine, but it blows up our Japanese translations
(via Smarty templates.)  Please do not claim it can be ignored or is a
Won't Fix as multi-language support is becoming more and more
necessary with PHP and this bug is causing major problems

#33997 [Opn]: Returned: Bug #16069 - ICONV transliteration failure

[RVaughn at pheedo dot com]

 ID:   33997
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
 Status:   Open
 Bug Type: ICONV related
 Operating System: Red Hat Ent. 3.0
 PHP Version:  4.4.0
 New Comment:

Q: How exactly does it fail.

A: Cannot reproduce here, as it's a string of Japanese multi-byte
characters which would just be garbage if cut and pasted here.  All I
can say is that any char buffer string of a size greater than 50? 60?
bytes long gets scrambled after that point, everything is fine up to it
but not after.

There's no way for me to post the Japanese characters and since I don't
speak Japanese, I am going on our developer in Japan's testing, and he
says that short strings are translating fine but longer ones get
garbled around that point.

Sorry that I can't provide more detailed info and cannot give you an
example, but if you run the test script in the PHP test suite as I
mentioned on this platform, you will get the same failure and the fact
that a PHP-provided test is failing should be enough to (1) reopen the
original bug #16069 as unresolved on this platform and (2) provide a
way to go about seeing the failure and trying to figure it out.
Thanks!


Previous Comments:


[2005-08-04 22:25:09] RVaughn at pheedo dot com

Was getting one warning in the 'make' output as reported, fixed the
code in:

.../php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c

and now do not get a warning in the 'make' but it did not fix the
problem, and multi-byte string output for Japanese text is being messed
up by this reopened? never-fixed? bug.

Here's the diff to fix the warning for encodings.c, very simple:

64c64
   char const *src_ptr = src;
---
   char* src_ptr = (char*) src;

It clearly states the iconv() parameters and you can't pass a 'const'
into the call, period.



[2005-08-04 20:25:57] [EMAIL PROTECTED]

How *exactly* does it fail?



[2005-08-04 20:23:24] RVaughn at pheedo dot com

Description:

In the PHP 4.4 test suite, the test for closed bug #16069 fails:

FAIL Bug #16069 [ext/iconv/tests/bug16069.phpt]

Checked the output and it does diverge from the expected output in the
same way the old bug from 2002 did.  The 'iconv' libraries are
up-to-date on the system:

# up2date glibc-common
The following packages you requested are already updated:
glibc-common

# rpm -qi glibc-common
Name: glibc-common   Relocations: (not relocatable)
Version: 2.3.2   Vendor: Red Hat, Inc.
Release: 95.33   Build Date: Wed 23 Feb 2005

The bug16069.phpt script will reproduce this every time.  Configured
with the following settings:

./configure  '--host=i386-redhat-linux' '--build=i386-redhat-linux'
'--target=i386-redhat-linux-gnu' '--cache-file=../config.cache'
'--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d'
'--enable-force-cgi-redirect' '--disable-debug' '--enable-pic'
'--disable-rpath' '--enable-inline-optimization' '--with-bz2'
'--with-db4=/usr' '--with-curl' '--with-freetype-dir=/usr'
'--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf'
'--without-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp'
'--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png'
'--with-aspell' '--with-regex=system' '--with-xml'
'--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr'
'--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre-regex=/usr'
'--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif'
'--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode'
'--enable-sockets' '--enable-sysvsem' '--enable-sysvshm'
'--enable-discard-path' '--enable-track-vars' '--enable-trans-sid'
'--disable-yp' '--enable-wddx' '--without-oci8'
'--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl'
'--with-kerberos' '--with-ldap=shared' '--with-mysql=shared,/usr'
'--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack'
'--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath'
'--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio'
'--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans'
'--enable-mbregex' '--with-apxs2=/usr/sbin/apxs'

Using a standard /etc/php.ini file that works fine under PHP 4.3.6
which we upgraded to several weeks ago and this bug does not appear to
be a problem with.

Got the following warning (the only one) when doing a 'make':

/usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c:
In function `convert':
/usr/local/src/Tars/php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c:74:
warning: passing arg 2 of `iconv' from incompatible pointer type

Guessing that the call to updated versions of 'libxml' or 'libxml2' is
the problem, here's the versions for both:

# rpm -qi libxml
Name: libxml

#33997 [Fbk-Opn]: Returned: Bug #16069 - ICONV transliteration failure

[RVaughn at pheedo dot com]

 ID:   33997
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
-Status:   Feedback
+Status:   Open
 Bug Type: ICONV related
 Operating System: Red Hat Ent. 3.0
 PHP Version:  4.4.0
 New Comment:

OK, here's the diff output from the test results, please note that the
output is the same until part way through, and the ultimate length is
different:

===
/usr/local/src/Tars/php-4.4.0/ext/iconv/tests/bug16069.phpt
===

 EXPECTED OUTPUT
¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë)
 ACTUAL OUTPUT
¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë)
 FAILED


Previous Comments:


[2005-08-04 22:42:12] [EMAIL PROTECTED]

If it fails, you should get *.diff file which clearly shows what did
you get instead of the result expected.
And you don't have to post something, you can just put the code and
it's output somewhere in the Net and post a link here.



[2005-08-04 22:29:10] RVaughn at pheedo dot com

Q: How exactly does it fail.

A: Cannot reproduce here, as it's a string of Japanese multi-byte
characters which would just be garbage if cut and pasted here.  All I
can say is that any char buffer string of a size greater than 50? 60?
bytes long gets scrambled after that point, everything is fine up to it
but not after.

There's no way for me to post the Japanese characters and since I don't
speak Japanese, I am going on our developer in Japan's testing, and he
says that short strings are translating fine but longer ones get
garbled around that point.

Sorry that I can't provide more detailed info and cannot give you an
example, but if you run the test script in the PHP test suite as I
mentioned on this platform, you will get the same failure and the fact
that a PHP-provided test is failing should be enough to (1) reopen the
original bug #16069 as unresolved on this platform and (2) provide a
way to go about seeing the failure and trying to figure it out.
Thanks!



[2005-08-04 22:25:09] RVaughn at pheedo dot com

Was getting one warning in the 'make' output as reported, fixed the
code in:

.../php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c

and now do not get a warning in the 'make' but it did not fix the
problem, and multi-byte string output for Japanese text is being messed
up by this reopened? never-fixed? bug.

Here's the diff to fix the warning for encodings.c, very simple:

64c64
   char const *src_ptr = src;
---
   char* src_ptr = (char*) src;

It clearly states the iconv() parameters and you can't pass a 'const'
into the call, period.



[2005-08-04 20:25:57] [EMAIL PROTECTED]

How *exactly* does it fail?



[2005-08-04 20:23:24] RVaughn at pheedo dot com

Description:

In the PHP 4.4 test suite, the test for closed bug #16069 fails:

FAIL Bug #16069 [ext/iconv/tests/bug16069.phpt]

Checked the output and it does diverge from the expected output in the
same way the old bug from 2002 did.  The 'iconv' libraries are
up-to-date on the system:

# up2date glibc-common
The following packages you requested are already updated:
glibc-common

# rpm -qi glibc-common
Name: glibc-common   Relocations: (not relocatable)
Version: 2.3.2   Vendor: Red Hat, Inc.
Release: 95.33   Build Date: Wed 23 Feb 2005

The bug16069.phpt script will reproduce this every time.  Configured
with the following settings:

./configure  '--host=i386-redhat-linux' '--build=i386-redhat-linux'
'--target=i386-redhat-linux-gnu' '--cache-file=../config.cache'
'--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d'
'--enable-force-cgi-redirect' '--disable-debug' '--enable-pic'
'--disable-rpath' '--enable-inline-optimization' '--with-bz2'
'--with-db4=/usr' '--with-curl' '--with-freetype-dir

#33997 [Opn]: Returned: Bug #16069 - ICONV transliteration failure

[RVaughn at pheedo dot com]

 ID:   33997
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
 Status:   Open
 Bug Type: ICONV related
 Operating System: Red Hat Ent. 3.0
 PHP Version:  4.4.0
 New Comment:

Do let me know if you want me to put the output somewhere on our site
where it can be downloaded, the code itself is just the PHP-provided
test: bug16069.phpt.  Thanks!  Cheers!


Previous Comments:


[2005-08-04 23:32:57] RVaughn at pheedo dot com

OK, here's the diff output from the test results, please note that the
output is the same until part way through, and the ultimate length is
different:

===
/usr/local/src/Tars/php-4.4.0/ext/iconv/tests/bug16069.phpt
===

 EXPECTED OUTPUT
¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë)
 ACTUAL OUTPUT
¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë)
 FAILED



[2005-08-04 22:42:12] [EMAIL PROTECTED]

If it fails, you should get *.diff file which clearly shows what did
you get instead of the result expected.
And you don't have to post something, you can just put the code and
it's output somewhere in the Net and post a link here.



[2005-08-04 22:29:10] RVaughn at pheedo dot com

Q: How exactly does it fail.

A: Cannot reproduce here, as it's a string of Japanese multi-byte
characters which would just be garbage if cut and pasted here.  All I
can say is that any char buffer string of a size greater than 50? 60?
bytes long gets scrambled after that point, everything is fine up to it
but not after.

There's no way for me to post the Japanese characters and since I don't
speak Japanese, I am going on our developer in Japan's testing, and he
says that short strings are translating fine but longer ones get
garbled around that point.

Sorry that I can't provide more detailed info and cannot give you an
example, but if you run the test script in the PHP test suite as I
mentioned on this platform, you will get the same failure and the fact
that a PHP-provided test is failing should be enough to (1) reopen the
original bug #16069 as unresolved on this platform and (2) provide a
way to go about seeing the failure and trying to figure it out.
Thanks!



[2005-08-04 22:25:09] RVaughn at pheedo dot com

Was getting one warning in the 'make' output as reported, fixed the
code in:

.../php-4.4.0/ext/xmlrpc/libxmlrpc/encodings.c

and now do not get a warning in the 'make' but it did not fix the
problem, and multi-byte string output for Japanese text is being messed
up by this reopened? never-fixed? bug.

Here's the diff to fix the warning for encodings.c, very simple:

64c64
   char const *src_ptr = src;
---
   char* src_ptr = (char*) src;

It clearly states the iconv() parameters and you can't pass a 'const'
into the call, period.



[2005-08-04 20:25:57] [EMAIL PROTECTED]

How *exactly* does it fail?



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/33997

-- 
Edit this bug report at http://bugs.php.net/?id=33997edit=1

#33997 [Asn-Csd]: Returned: Bug #16069 - ICONV transliteration failure

[RVaughn at pheedo dot com]

 ID:   33997
 User updated by:  RVaughn at pheedo dot com
 Reported By:  RVaughn at pheedo dot com
-Status:   Assigned
+Status:   Closed
 Bug Type: ICONV related
 Operating System: Red Hat Ent. 3.0
 PHP Version:  5CVS, 4CVS (2005-08-04)
 Assigned To:  yohgaki
 New Comment:

Works perfectly!  Hopefully this patch can be rolled into PHP 4.4.1? 
This one can be closed, that was the fix.  Thanks much!  Cheers!


Previous Comments:


[2005-08-05 00:39:44] [EMAIL PROTECTED]

This seems to fix the problem:

http://www.php.net/~jani/patches/bug33997.patch

I now get the correct result which I also got with the command line
iconv tool.




[2005-08-04 23:34:18] RVaughn at pheedo dot com

Do let me know if you want me to put the output somewhere on our site
where it can be downloaded, the code itself is just the PHP-provided
test: bug16069.phpt.  Thanks!  Cheers!



[2005-08-04 23:32:57] RVaughn at pheedo dot com

OK, here's the diff output from the test results, please note that the
output is the same until part way through, and the ultimate length is
different:

===
/usr/local/src/Tars/php-4.4.0/ext/iconv/tests/bug16069.phpt
===

 EXPECTED OUTPUT
¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë)
 ACTUAL OUTPUT
¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë¥ß¥ê¥Ð¡¼¥ë(¡ë§¥¡ë)
 FAILED



[2005-08-04 22:42:12] [EMAIL PROTECTED]

If it fails, you should get *.diff file which clearly shows what did
you get instead of the result expected.
And you don't have to post something, you can just put the code and
it's output somewhere in the Net and post a link here.



[2005-08-04 22:29:10] RVaughn at pheedo dot com

Q: How exactly does it fail.

A: Cannot reproduce here, as it's a string of Japanese multi-byte
characters which would just be garbage if cut and pasted here.  All I
can say is that any char buffer string of a size greater than 50? 60?
bytes long gets scrambled after that point, everything is fine up to it
but not after.

There's no way for me to post the Japanese characters and since I don't
speak Japanese, I am going on our developer in Japan's testing, and he
says that short strings are translating fine but longer ones get
garbled around that point.

Sorry that I can't provide more detailed info and cannot give you an
example, but if you run the test script in the PHP test suite as I
mentioned on this platform, you will get the same failure and the fact
that a PHP-provided test is failing should be enough to (1) reopen the
original bug #16069 as unresolved on this platform and (2) provide a
way to go about seeing the failure and trying to figure it out.
Thanks!



The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/33997

-- 
Edit this bug report at http://bugs.php.net/?id=33997edit=1