php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #10292 Corrupted VARCHAR values from SELECT when used in arrays or array functions
Submitted: 2001-04-11 14:35 UTC Modified: 2001-05-03 03:32 UTC
From: lawe at tdk dot dk Assigned:
Status: Closed Package: InterBase related
PHP Version: 4.0.4pl1 OS: Linux / Windows
Private report: No CVE-ID: None
View Developer Edit
 [2001-04-11 14:35 UTC] lawe at tdk dot dk 
// f1 and f2 are of type varchar
$id=ibase_query($tr_id, "SELECT f1, f2 FROM t1;");
$res = ibase_fetch_row($id);
echo "'".$res[0]."'";  // Working fine
$arr[$res[0]] = 1;
$arr[$res[1]] = 2;
foreach ($res as $r => $v)
  echo "'$r'\n";     // will in some cases add unexpected
                     // characters to end of $r
                     // It is the same with each construct
// The same applies to ibase_fetch_object()

The values in the database are correct, as the unwanted characters may vary depending on the number of columns in the select-statement. But it is always the same characters on repeated executions.
I have made a work-around in a way like this:
$arr[str_pad($res[0], -1)] = 1;

I think it has something to do with the Interbase-API, as it is the same errors regardless of the Webserver (Apache 1.3.14 & 1.3.19, PHP 4.0.4pl1 or Win9x PWS, CGI or ISAPI version of PHP 4.0.4pl1) connecting to Interbase 6.01 on RedHat 6.1 and RedHat 6.2

The bug was first observed when doing a split(), where the last element in the resulting array had strange characters attached to the end.

PHP configured with minimal changes to defaults (Interbase support, enable-track-vars).

Hope this is sufficient information, otherwise write me for further info, and I will try to deliver it (if I can).

Regards
/Lars

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-04-23 04:31 UTC] lawe at tdk dot dk 
Hi!

I finally found the bug myself. And it was indeed in ./ext/interbase.c

Normally you would terminate a string explicitly after a strncpy(), but one should think this was unnecessary in this part of the code, as the string-length is part of the variable-structure. Nevertheless I added a statement which filled in the missing zero to end the string, and Voila! All the strange characters disappeared. Could it be, that the code handling the PHP-arrays doesn't use the len-parameter, but only uses the estrdup() function (which assumes a correctly terminated string)?

In the same function I also discovered a memoryleak when handling magic-quotes, so the final diff between the new interbase.c and the old one (version 1.48) looks like this (I have removed many of the leading spaces):

$ diff interbase.c interbase.orig.c
1009c1009
< IB_ARRAY[ar_cnt].el_type = SQL_VARYING;
---
> IB_ARRAY[ar_cnt].el_type = SQL_TEXT;
1731d1730
<           val->value.str.val[len] = 0;
1733c1732,1738
< val->value.str.val = php_addslashes(val->value.str.val, len, &len, 1);  /* Old string should be deleted */
---
> /*
> char *tmp = val->value.str.val;
> */
> val->value.str.val = php_addslashes(val->value.str.val, len, &len, 0);
> /*
> efree(tmp);
> */
$

The first change is questioned in the code, so I just changed it! - and from my testing there wasn't any changed (or erroneous) behaviour noticed.
The two other changes are the string-termination bugfix and the memory-leak bugfix.

I have seen another bugreport concerning the formatting of the floating-point datatypes - I am currentliy not using floating-point fields in my databases, but maybe one should take a look at the FP-handling in the same function (_php_ibase_var_pval())?

Yours sincerely,
Lars

PS! Keep up the good work - PHP is great!
 [2001-05-03 03:32 UTC] sniper@php.net 
Should be fixed in CVS now.

--Jani
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Nov 05 07:00:01 2025 UTC