#33997 [Opn]: Returned: Bug #16069 - ICONV transliteration failure
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 [Opn]: Returned: Bug #16069 - ICONV transliteration failure
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
