php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60052 Integer returned as a 64bit integer on X64_86
Submitted: 2011-10-13 13:01 UTC Modified: 2015-12-04 16:48 UTC
Votes:8
Avg. Score:4.8 ± 0.7
Reproduced:8 of 8 (100.0%)
Same Version:0 (0.0%)
Same OS:4 (50.0%)
From: m dot vanduren at jonker dot nl Assigned: mariuz (profile)
Status: Closed Package: PDO Firebird
PHP Version: 5.3.8 OS: All (linux tested)
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 you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: m dot vanduren at jonker dot nl
New email:
PHP Version: OS:

 

 [2011-10-13 13:01 UTC] m dot vanduren at jonker dot nl
Description:
------------
Integer on firebird is treated as a 32 bit int and int64 is used as a 64 bit integer.
In the pdo_firebird driver INT64 is not implemented and LONG (int32) is treated as a long integer. On an x86_64 machine this means that a SQL_LONG doesn't honor the bit-sign in a value and INT64 doesn't return anything.

This patch should fix this value for x86_64 systems while leaving x86 systems unchanged.

Test script:
---------------
any firebirdSQL database with a integer field containing a negative value.
retrieve the value with the pdo_firebird driver on a 64 bit machine and echo it to the screen.

Expected result:
----------------
negative values with integer and should be returned as a negative number.

Actual result:
--------------
negative values are returned as their unsigned counterpart.

Patches

php5-bug60052.patch (last revision 2013-09-26 06:21 UTC by slavb18 at gmail dot com)
integer_x86_64.patch (last revision 2011-10-13 13:03 UTC by m dot vanduren at jonker dot nl)

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-11-16 00:36 UTC] felipe@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: felipe
 [2011-12-28 15:48 UTC] mariuz@php.net
-Package: InterBase related +Package: PDO related -Assigned To: felipe +Assigned To: mariuz
 [2012-04-02 14:04 UTC] mariuz@php.net
LL_MASK it should be already be "l" see the php_pdo_firebird_int.h:# define 
LL_MASK "l"

So in the in the slprintf 
slprintf(*ptr, CHAR_BUF_LEN, "%" LL_MASK "d", *(ISC_INT64*)var->sqldata);
should be replaced with 

slprintf(*ptr, CHAR_BUF_LEN, "%" "l" "d", *(ISC_INT64*)var->sqldata);

I will check and create a test for 5.3.x
 [2013-09-25 18:22 UTC] slavb18 at gmail dot com
why this patch only partially accepted? still not working on x86-64
$q="select * FROM RDB\$DATABASE";
$q="execute block
returns (
rI integer)
as
begin
rI= -1;
suspend;
end";
$res=$pdo->dbExecute($q);
print_r($res->fetch());

outputs
Array
(
    [RI] => 4294967295
    [0] => 4294967295
)
istead of
Array
(
    [RI] => -1
    [0] => -1
)
 [2013-10-07 08:51 UTC] mariuz@php.net
I will recheck and apply it (the patch)
 [2014-01-01 12:41 UTC] felipe@php.net
-Package: PDO related +Package: PDO Firebird
 [2014-01-03 02:40 UTC] papatiger+phpbug at gmail dot com
Why are many serious bugs of pdo.firebird not revised?
I cannot use ORM such as DBAL in Firebird.
 [2014-01-15 06:58 UTC] slavb18 at gmail dot com
may be it's time to move to Java with native POJO ? )
 [2014-01-15 06:59 UTC] slavb18 at gmail dot com
bug and patch are three years old, looks like this is not need to anybody
 [2014-09-23 04:02 UTC] andreas dot prucha at gmail dot com
I am running into the same problem and it seems that it's still not fixed (at least I do not find any relevant changes in the repository).

Maybe Firebird is not as popular as other DBMS, but I cannot imagine that nobody needs negative values in 32bit-integers.

Andreas
 [2015-11-04 13:52 UTC] bjoern dot vh at gmx dot de
I am such dissapointed: the problem is still not fixed in current PHP 7.0 RC6 :-(

Please, please fix it...
 [2015-12-02 15:35 UTC] matthew dot jones at ramtech dot co dot uk
Does this confirm that nobody actually uses Firebird? For a bug like this, which effects simple day to day operations such as wanting to use a negative number, to remain open, despite a patch having been offered, for this many years, I find incredible.

I ported code from ibase specific stuff to PDO in anticipation of having to ditch Firebird for other reasons. This confirms its fate.
 [2015-12-03 14:16 UTC] mariuz@php.net
Automatic comment on behalf of mapopa@gmail.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=4173a667fab0c77d1704a6b9d9a8e6ab1209ff72
Log: Fix Bug #60052	Integer returned as a 64bit integer on X64_86 for pdo_firebird
 [2015-12-03 14:16 UTC] mariuz@php.net
-Status: Assigned +Status: Closed
 [2015-12-03 14:25 UTC] mariuz@php.net
Automatic comment on behalf of mapopa@gmail.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=4173a667fab0c77d1704a6b9d9a8e6ab1209ff72
Log: Fix Bug #60052	Integer returned as a 64bit integer on X64_86 for pdo_firebird
 [2015-12-03 14:26 UTC] mariuz@php.net
Automatic comment on behalf of mapopa@gmail.com
Revision: http://git.php.net/?p=php-src.git;a=commit;h=4173a667fab0c77d1704a6b9d9a8e6ab1209ff72
Log: Fix Bug #60052	Integer returned as a 64bit integer on X64_86 for pdo_firebird
 [2015-12-04 10:09 UTC] matthew dot jones at ramtech dot co dot uk
The commited patch doesn't work. The change bellow appends "ld" to the number.

-					*len = slprintf(*ptr, CHAR_BUF_LEN, "%" LL_MASK "d", *(ISC_INT64*)var->sqldata);
+					*len = slprintf(*ptr, CHAR_BUF_LEN, "%ld" LL_MASK "d", *(ISC_INT64*)var->sqldata);

I think just the single change in the earlier patch is required. At least that worked for me.
 [2015-12-04 10:34 UTC] slavb18 at gmail dot com
we are using php5-bug60052.patch with single change since 2013-09-26, no problems
 [2015-12-04 16:48 UTC] mariuz@php.net
I have reverted that patch , it wasn't needed 

https://github.com/php/php-src/commit/8da575231101e240db0670cd9f3105e9cb07e071
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 12:01:29 2024 UTC