php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67484 PDO::FETCH_OBJ mode > property name with invisible NUL ASCII charact. @ the end
Submitted: 2014-06-20 08:12 UTC Modified: 2021-04-11 04:22 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: max dot rault at gmail dot com Assigned: cmb (profile)
Status: No Feedback Package: PDO_IBM (PECL)
PHP Version: 5.5.13 OS: i5/OS V7R1
Private report: No CVE-ID: None
 [2014-06-20 08:12 UTC] max dot rault at gmail dot com
Description:
------------
When you fetch data with PDO::FETCH_OBJ mode you obtain an object with property names that correspond to the column names returned in the result set.

So for example for this table:
User : id, name

you'll have an object:
User->id, User->name.

The problem is that with PDO_IBM, in any case PDO_IBM on ibmi, you obtain an object with property names that effectively correspond to the column names returned in the result set but also with a NUL ASCII charater (ASCII code "0") at the end !

When you var_dump the object you don't see that character at all. It is invisible. But it is obviously there.
So you have in reality an object which looks like: User->id"NUL", User->name"NUL".
The lengths of property names are a character longer than they should be.

So if, in your code, you try to display a value, for instance the name value, usually you do:
<?php
echo $user->name // this code fails
?>

But if you write:
<?php
$nameProperty = "name" . chr(0); // Concatenate the NUL code ASCII at the end
echo $user->$nameProperty; // this code works
?>

This is amazingly weird. There is no problem with PDO_MYSQL. I checked it.
So the issue seems to come from PDO_IBM driver.

Test script:
---------------
$database = "I1GIGC1";
$user = "MRAULT";
$pwd = "******";

$statement = "select ADH, NOM from coperl1.cprlnoms where adh in (10002, 10050)";

try {
    $db = new PDO("ibm:" . $database, $user, $pwd, 
                      array(PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION,
                            PDO::ATTR_AUTOCOMMIT => true,
                            PDO::ATTR_PERSISTENT => false
                      )
                  );

    $query = $db->query($statement);
    $cprlnoms = $query->fetchAll(PDO::FETCH_OBJ);
    foreach ($cprlnoms as $cprlnom) {
        var_dump($cprlnom);
        echo '<br>/* echo $cprlnom object properties as usual => Epic fail */<br>';
        echo '<br>KO with $cprlnom->ADH = ' . $cprlnom->ADH;
        echo '<br>KO with $cprlnom->NOM = ' . $cprlnom->NOM;
        echo '<br><br>/* echo $cprlnom object properties with freaky NUL ASCII character at the end => WTF it works ! */<br>';
        $adhProperty = "ADH" . chr(0);
        $nomProperty = "NOM" . chr(0);
        echo 'OK with $cprlnom->ADH.chr(0) = ' . $cprlnom->$adhProperty;
        echo '<br>OK with $cprlnom->NOM.chr(0) = ' . $cprlnom->$nomProperty;
}


Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-07-16 07:04 UTC] max dot rault at gmail dot com
Same problem with FETCH_CLASS of course.
 [2014-07-24 10:24 UTC] rahulpriyadarshi@php.net
You are facing this issue when your application is running on i5/OS PASE or your aaplication is on LUW and DB2 server on i5/OS.
 [2014-07-24 10:32 UTC] max dot rault at gmail dot com
Actually the PHP is executed directly on ZendServer for IBMi.
So yes I'm facing this issue in i5/OS PASE environnement.

Guys from Zend are aware of this issue and they could reproduce it.
 [2021-03-31 10:58 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-03-31 10:58 UTC] cmb@php.net
Does this still happen with latest PDO_IBM?  If so, is the null
character also part of the column name with PDO::FETCH_BOTH?  You
can visualize this by printing out the column name after bin2hex()
it, for instance.
 [2021-04-11 04:22 UTC] pecl-dev 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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Nov 04 01:01:29 2024 UTC