Edit report at https://bugs.php.net/bug.php?id=81688&edit=1
ID: 81688
Updated by: cmb@php.net
Reported by: calvin at cmpct dot info
Summary: PDO_ODBC doesn't handle fixed-length character
columns with character conversio
-Status: No Feedback
+Status: Open
Type: Bug
Package: PDO ODBC
Operating System: IBM i 7.2
PHP Version: 8.0.13
Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
Sorry for the late reply!
From what I can tell, there may be two different issues here: (a)
PHP does not allocate sufficient space for the data, and (b) the
driver may deliver fewer data than PHP expects, resulting in
arbitrary memory contents to be given to userland. Let's focus
on (b) for now, since that should be easy to fix by zeroing the
buffers before fetching. Could you please try the following patch
for ODBC (PDO_ODBC could likely get a similar fix):
ext/odbc/php_odbc.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/ext/odbc/php_odbc.c b/ext/odbc/php_odbc.c
index d4de4ec75b..d0ee19aa07 100644
--- a/ext/odbc/php_odbc.c
+++ b/ext/odbc/php_odbc.c
@@ -1381,6 +1381,12 @@ static void php_odbc_fetch_hash(INTERNAL_FUNCTION_PARAMETERS, int
result_type)
RETURN_FALSE;
}
+ for (i = 0; i < result->numcols; i++) {
+ if (result->values[i].value != NULL) {
+ memset(result->values[i].value, 0, result->values[i].vallen);
+ }
+ }
+
#ifdef HAVE_SQL_EXTENDED_FETCH
if (result->fetch_abs) {
if (rownum > 0) {
Something else that may be worth investigating is the usage of
SQL_LONGVARCHAR columns (or respective casts), if something like
that is supported by the DB and the driver. Such columns are not
bound, but rather SQLGetData() is used to retrieve the data, and
the driver is supposed to report the length of the transferred
data in the StrLen_or_IndPtr argument (so in this case neither
SQLDescribeCol() nor SQLColAttribute() are used to compute the
length).
Previous Comments:
------------------------------------------------------------------------
[2021-12-27 13:56:18] calvin at cmpct dot info
The problem still exists, it should be re-opened.
That said, I'm not entirely sure of the etiquette though around bugs on bugs.php; are these
better off moved to GH Issues instead now?
------------------------------------------------------------------------
[2021-12-26 04:22:08] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
------------------------------------------------------------------------
[2021-12-14 18:53:44] calvin at cmpct dot info
I can confirm that PDO::ODBC_ATTR_ASSUME_UTF8 and using the procedural ODBC extension have the same
results. (Well, the garbage on the end is different, but it's still garbage and the string is
still the same length.)
Code for the procedural ODBC version (the attrib on PDO ver is trivial so not including):
```
$odbc = odbc_connect($dsn, $user, $pw);
$sql = "select cast(x as char(150)) as X from calvin.bigchars";
$stmt = odbc_prepare($odbc, $sql);
echo "before ODBC\n";
var_dump(odbc_execute($stmt));
echo "after ODBC\n";
while($record = odbc_fetch_array($stmt)){
echo "Record\n";
var_dump($record["X"]);
}
```
------------------------------------------------------------------------
[2021-12-14 13:47:41] cmb@php.net
Oh, forgot: could you also please check the results of the queries
with ext/odbc (i.e. the odbc_*() functions)? The implementation
is quite different from PDO_ODBC.
------------------------------------------------------------------------
[2021-12-14 13:11:03] cmb@php.net
> Of course, the link to the Appendix isn't any more enlightening:
Yeah. :(
Anyhow, all this looks remotely related to bug #79059; see
particularly my last comment there[1]. It might be worthwhile to
try to run the scripts with PDO::ODBC_ATTR_ASSUME_UTF8 set to
true, even though that is not yet consistently implemented.
[1] <https://bugs.php.net/bug.php?id=79059#1601993047>
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=81688
--
Edit this bug report at https://bugs.php.net/bug.php?id=81688&edit=1