php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #24796 Error in handling INT64 type value
Submitted: 2003-07-24 11:42 UTC Modified: 2003-07-31 11:38 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: acdweb at yahoo dot com Assigned:
Status: Closed Package: InterBase related
PHP Version: 4.3.2 OS: Redhat Linux 9.0
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: acdweb at yahoo dot com
New email:
PHP Version: OS:

 

 [2003-07-24 11:42 UTC] acdweb at yahoo dot com
Description:
------------
Hello!

PROBLEM: value "0" is replaced with "" when var type is INT64
REASON: a bug when casting INT64 to STRING
FILENAME: interbase.c
FUNCTION: static int _php_ibase_var_pval()

Original Code:

#ifdef SQL_INT64
		case SQL_INT64:
			val->type = IS_STRING;

			if (scale) {
				int j, f = 1;
				double number = (double) ((ISC_INT64) (*((ISC_INT64 *)data)));
				char dt[20];
				for (j = 0; j < -scale; j++) {
					f *= 10;
				}
				sprintf(dt, "%%0.%df", -scale);
				val->value.str.len = sprintf (string_data, dt, number/f );
			} else {
			  val->value.str.len =sprintf (string_data, "%.0" ISC_INT64_FORMAT "d",
			    	             					(ISC_INT64) *(ISC_INT64 *) data);
			}

			val->value.str.val = estrdup(string_data);
			break;
#endif

Fixed Code:

#ifdef SQL_INT64
		case SQL_INT64:
			val->type = IS_STRING;

			if (scale) {
				int j, f = 1;
				double number = (double) ((ISC_INT64) (*((ISC_INT64 *)data)));
				char dt[20];
				for (j = 0; j < -scale; j++) {
					f *= 10;
				}
				sprintf(dt, "%%0.%df", -scale);
				val->value.str.len = sprintf (string_data, dt, number/f );
			} else {
			  if ((ISC_INT64) *(ISC_INT64 *) data == 0) {
				  val->value.str.len =sprintf (string_data, "0");
			  }
			  else {
				  val->value.str.len =sprintf (string_data, "%.0" ISC_INT64_FORMAT "d",
			    	             					(ISC_INT64) *(ISC_INT64 *) data);
			  }
			}

			val->value.str.val = estrdup(string_data);
			break;
#endif


Thank you for your work!

Justin Kang

Reproduce code:
---------------
print_r($result)

Expected result:
----------------
Array
(
    [ID] => 3
    [BLEED] => 0
    [DESCRIPTION] => Front Side
)

Actual result:
--------------
Array
(
    [ID] => 3
    [BLEED] => 
    [DESCRIPTION] => Front Side
)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-07-24 14:25 UTC] sniper@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

The code has changed quite a lot, please give it a go.
also, if the problem persists, can you please give us 
a complete test script(s) to reproduce this problem?
(with db creation script too)

 [2003-07-29 07:26 UTC] sniper@php.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 "Open". Thank you.


 [2003-07-31 11:10 UTC] acdweb at yahoo dot com
To: sniper@php.net 

This problem still exist in latest PHP. The only reason that "I" no longer experience the problem is that "I fixed my source" and compiled myself. I'm reporting this bug to help fellow Phpers.
 [2003-07-31 11:38 UTC] acdweb at yahoo dot com
Sorry that I didn't notice the function in interbase module in php4.3.3 is totally re-written.

By looking at the new source code, I see the problem has been fixed now

Thanks.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Mar 29 06:01:29 2024 UTC