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 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: 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 18:01:29 2024 UTC