php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #14278 % and / bug with INTEGERs!
Submitted: 2001-11-29 05:27 UTC Modified: 2002-05-14 00:00 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: pumuckel at metropolis dot de Assigned:
Status: No Feedback Package: OCI8 related
PHP Version: 4.0.6 OS: Linux 2.2.19
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: pumuckel at metropolis dot de
New email:
PHP Version: OS:

 

 [2001-11-29 05:27 UTC] pumuckel at metropolis dot de 
Sometimes (1 - 10 times a day) I get a strange error on one of my production servers. See this function:

function MakeHash($num) {
  $ret = "";
  $ca = array();
  for ($i = 0; $i < 6; $i++) {
    $c = $num % 26;
    $ca[] = "$num $c";   
    $ret = sprintf("%c", 65+$c).$ret;
    $num = ($num-$c)/ 26;
  }
  // Send $ca array via email to me.... (removed)
  return $ret;
}

Sometimes calling this function with an INT it calculates wired results... If that happens I mail the $ca array to myself and see what it does:

101110 19          (MEANS: 101110 % 26 is 19!? That's wrong, it is 22)
38888588 24       (MEANS 101110 / 26 is 38888588, but it is 3888)
1495714 12        ...
57527 15
2212 2
85 7

What goes wrong? In the beginning the % result is wrong, and then the division result is wrong too...  any suggestions!?

 /mike

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-11-29 15:42 UTC] cnewbill@php.net 
E:\php>php -v
4.0.6

E:\php>php -q test.php
101110 22
3888 14
149 19
5 5
0 0
0 0
AAFTOW

No matter how many times I run this script I always get this.  Also tested it on Linux (2.4), with PHP 4.2.0-dev and it works.

Please try a newer version and see if that fixes the problem you're having. http://www.php.net/~zeev/php-4.1.0RC3.tar.gz or http://snaps.php.net/php4-latest.tar.gz

-Chris
 [2001-12-20 12:48 UTC] sander@php.net 
No feedback. Closing.
 [2002-01-09 09:17 UTC] pumuckel at metropolis dot de 
After some more investigation on this bug I noticed following:

I have an OCI insert statement executed with a 'RETURNING INTO' clause. The value which is returned is a oracle DB entry of type NUMBER. I expected to have the returned value in PHP to be a number as well. BUT it is a string!

Some more output I produced in my script is:

<? echo("$num (type: ".gettype($num)."[".strlen($num)."] - ".($num*1).")"); ?>

The result (when the error occures):
106851 (type: string[6] - 1068514)

As you can see the value of the $num variable changes while automatic type casting from string to int is executed.

The reason for the NEW (bigger) value is possibly a not null terminated string value returned by the OCI interface.

My suggestion: While typecasting from string to int an extra check should be done (e.g. detect if there is a null terminated string and if not: terminate it).

Thanks for your patch!
 [2002-04-09 18:12 UTC] jimw@php.net 
recategorizing as an oci8 issue.
 [2002-04-13 09:00 UTC] thies@php.net 
all scalar values returned from PHP-OCI8 are strings.
 [2002-04-13 09:02 UTC] thies@php.net 
oops - closed to fast.

please send me a short _SELF_ contains script that shows the problem (including the oci-calls)
 [2002-05-14 00:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2002-05-14 04:47 UTC] pumuckel at metropolis dot de 
FYI: Has been fixed in OCI interface. Error was not null terminated strings.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 13:01:31 2024 UTC