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
 [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: Mon Dec 30 14:01:28 2024 UTC