php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #5444 Long VARCHARs create invalid strings
Submitted: 2000-07-07 21:23 UTC Modified: 2006-07-17 09:05 UTC
From: schmidt at bcc dot de Assigned:
Status: Not a bug Package: OCI8 related
PHP Version: 4.0.1pl2 OS: linux 2.2 / glibc 2.1.3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
34 - 15 = ?
Subscribe to this entry?

 
 [2000-07-07 21:23 UTC] schmidt at bcc dot de
Any select command on VARCHARS (256+) does not return a "regular" string, but (following a tcpdump) contains 0<CHAR>0<CHAR>0<CHAR>...
This causes a non-display with Netscape (not even visible in page source) 4.7x on Linux & Win (at least). Lynx and MSIE (at least) do work.
I consider this a bug, as with PHP 3 the output was valid (and visible with Netscape).

I'm using Oracle 8.0.5.0.0 Linux - my PHP configuration command was
--without-pgsql --without-mysql --with-oci8 --with-zlib --sysconfdir=/etc --without-gd --with-apxs
The webserver is not the same as the db machine, if this matters.

The table is like 
create table tab (col1 varchar(256), col2 varchar(256), col3 varchar(256))
and the code used to print looks like

function _db_nextresult($result) {
        if (OCIFetchInto($result, $fetcharray, OCI_ASSOC)) {
                return $fetcharray;
        } else {
                return false;
        }
}

for ($result_b = _db_nextresult ($result), $i=0; $result_b; $i++) {
        while (list ($key, $val) = each ($result_b) ) {
                echo "$key - $val<BR>";
        }
        $result_b = _db_nextresult ($result);
 }

Note that with 
printf ("%s - %s<BR>\n", $key, $val);
you wan't see a single thing, not even with lynx or MSIE, as IMHO the zero in the string terminates it before the first character is printed. It also becomes quite difficult to parse the string and replace the zeroes....

If you want to take a look at it, feel free to visit
http://something.bcc.de/test.php for a php test and
http://something.bcc.de/t2.php for the problem...

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-07-07 22:53 UTC] schmidt at bcc dot de
It appears not to depend on the length of the varchars, but it works on a BSD box where I still have to find the configure params...
Maybe it's a NLS or UTF or something else character encoding specific. The data presented by Oracle already contains the zeroes (text is "admin", retlen=10). A side effect of this is, a 8 chars text in a varchar(10) can't be read and is truncated, a 18 chars text in a varchar(20) is cut after the first char, and it doesn't throw a warning...
OCIDebug: _oci_make_zval: CUSTID,retlen = 11,retlen4 = 0,storage_size4 = 11,indicator 0, retcode = 0
for "longtest", 
0a40  0a 43 55 53 54 49 44 20  2d 20 00 6c 00 6f 00 6e   .CUSTID. -..l.o.n 
0a50  00 67 00 74 00 3c 42 52  3e 4e 41 4d 45 20 2d 20   .g.t.<BR >NAME.-. 
is returned.
OCIDebug: _oci_make_zval: NAME,retlen = 1,retlen4 = 0,storage_size4 = 21,indicator 0, retcode = 0
OCIDebug: _oci_make_zval: PASSWORD,retlen = 2,retlen4 = 0,storage_size4 = 21,indicator 0, retcode = 0
 [2000-07-09 13:06 UTC] thies at cvs dot php dot net
please make sure that ORACLE_HOME, ORACLE_SID and NLS_LANG are setted in your environment *before* you start apache. do not use PutEnv() in your php-script or SetEnv in your httpd.conf or .htaccess.

 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 18 19:01:30 2024 UTC