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: 2014-07-24 10:32 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: max dot rault at gmail dot com Assigned:
Status: Open Package: PDO_IBM (PECL)
PHP Version: 5.5.13 OS: i5/OS V7R1
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: max dot rault at gmail dot com
New email:
PHP Version: OS:

 

 [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

Add a Patch

Pull Requests

Add a Pull Request

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.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Sun Aug 25 23:01:28 2019 UTC