The Number 9 Is EVIL !

I'm using Windows XP Pro SP2 and PHP v4.4.4 installed on Microsoft IIS v5.*

I have been going insane because I think I've found a bug in PHP, or at least a strange problem that I can't seem to easily resolve. It has been causing some mysterious computational failures giving erroneous numeric results.

Is there someone here who can test a simple PHP function and see if they get a similar result?

I've never seen a problem like this before.




This following code prints out the value 5 when I run it.

[code]

<?PHP

print test(05);



function test ($arg)

{

return $arg;

}

?>

[/code]


If I change the digits 05 to something else, such as 07, then it will print 7 as the result. That's what it should do. Nothing wrong with that.

Try changing the digits 05 to 0* and see what happens.

Every time I do that, I get 0 as the result!

Why does it fail ONLY if the digits are 0*?


I'm making a time input interface where the user enters the time as HH MM SS into three 2-digit text boxes on a form, one box for each time element.

A time such as 0*:0*:0* should also be able to be entered as *:*:*, but I can't get it to work that way.

The user should be able to enter a time as 06 or simply as 6 for 6 hours, minutes or seconds and shouldn't have to worry about the leading zero.

It seems to be only when the hours, minutes or seconds is 0*, that it fails and reads as zero. If I simply enter *, then it works perfectly! All other values from 00 to 08 work OK. The problem only occurs if the value is 0*.

I think it's a big, stinky, slimy PHP bug.

It took a long time to figure out why my computations were only occasionally wrong for an unknown reason and that bug(?) seems to be the cause of the problem.

The same result occurs even if more than one zero or more than one * is used.

For example, in the above function, the argument 000** returns zero and 00077* returns 6* !

The number * is evil, I tell you, EVIL !!!

Arghhhhhhhh!

I just want to know if the problem occurs for others using the same code or if the problem is unique to me.




PS: Apparently it happens with 08 too!

Rats!

When you put in the number 0 before any number it makes it octal. Octal numbers (base 8) only go from 0-7. That's why you have a bug.

[QUOTE=Moonbat;2**72]When you put in the number 0 before any number it makes it octal. Octal numbers (base 8) only go from 0-7. That's why you have a bug.[/QUOTE]

That's all I need - an 8-legged bug!

I was unaware that PHP worked like that! It seems like anything entered as purely numeric from the key***rd should be interpreted as a normal base *0 number by default! They should use a special symbol to indicate binary, octal or hex and no symbol would default to base *0.

Don't computer engineers ever think like real people? The computer should conform to a human's way of thinking, not the other way around!

If I was the dictator, I'd have someone shot for this!
LOL

If I put the digits inside quotes, then it treats everything like base *0, but I don't want the user to have to bother with that.

I found a simple workaround to the problem, so zeros won't cause anymore problems.

Also, I just upgraded to the horrors of PHP v5.2.4 At first, few of my programs worked because they changed the code used to POST a form and I couldn't find anything about that at the PHP site.

Any interactive program using $HTTP_POST_VARS will instantly break. Billions of my pages need to be changed to work with PHP 5.


Thanx for the info

:)

In your php just use (int) $_POST['time_piece'] when you set your variables. Not sure if you know what type-casting is but it makes life a lot easier sometimes.
[url]http://us*.php.net/manual/en/language.types.type-j***ling.php#language.types.typecasting[/url]

This is what I was forced to do with the insane "Hello World!" that I wrote. I wanted to make all the numbers line up for some crazy, odd, OCD reason so I wrote * as "0*" but when I

REPLY TO MY REPLY: Just noticed you found a work around already...

[QUOTE=JayT;2**7*]I was unaware that PHP worked like that![/QUOTE]

C++ works like that as well. I think Perl might, but I'm not sure.

[CODE]* = * in Base *0
0* = * in Base 8
0x* = * in Base *6
[/CODE]
As for binary, I don't know how to do that.

[QUOTE=SyntaX******;2**75]In your php just use (int) $_POST['time_piece'] when you set your variables. Not sure if you know what type-casting is but it makes life a lot easier sometimes.
[url]http://us*.php.net/manual/en/language.types.type-j***ling.php#language.types.typecasting[/url]
[/QUOTE]

Yeah, PHP type-casts automatically depending on context.

For example, if you use an integer into the print() function, it prints the number as a string.

[QUOTE=SyntaX******;2**75]In your php just use (int) $_POST['time_piece'] when you set your variables. Not sure if you know what type-casting is but it makes life a lot easier sometimes.
[url]http://us*.php.net/manual/en/language.types.type-j***ling.php#language.types.typecasting[/url]

This is what I was forced to do with the insane "Hello World!" that I wrote. I wanted to make all the numbers line up for some crazy, odd, OCD reason so I wrote * as "0*" but when I

REPLY TO MY REPLY: Just noticed you found a work around already...[/QUOTE]


I'm familiar with type casting, but it didn't work in this case.

When I enter it from a form text box, it is interpreted as a string, then I simply get the floating point value of the string and it works OK, regardless of the extra zero.

When I tested the function from the key***rd, it kept interpreting 0* as zero.

As a result, *0:0* would be treated as identical to *0:00, which is not good when trying to predict the details of an eclipse to the nearest second.
LOL

Every time one of the date or time elements was 0*, I would get erroneous computations. It took a long time to find out why because I thought that any number I entered from the key***rd would be considered a normal base *0 number.

I often test my functions by calling them with numeric arguments just to make sure they work correctly before building a web page around them.



Note the difference between the outputs of

[code]print DoubleVal(0*); // = 0[/code]

and

[code]print DoubleVal("0*"); // = *[/code]

and

[code]print (int)0*; // = 0[/code]


and

[code]print (int)"0*"; // = *[/code]


and

[code]print (string)0*; // = 0[/code]


and

[code]print (string)"0*"; // = *[/code]

ugh!

[QUOTE=JayT;2****][code]print DoubleVal(0*); // = 0[/code][/QUOTE]

That number doesn't exist in octal, so it outputs zero as an indication of an error.

0-20 (decimal) in octal:

0, *, 2, *, 4, 5, 6, 7, *0, **, *2, **, *4, *5, *6, *7, 20, 2*, 22, 2*, 24

I think I got my octal-counting right there.

[QUOTE][code]print DoubleVal("0*"); // = *[/code][/QUOTE]

It assumes it's denary (decimal) and discards the zero since you only have units, not tens.

0000000* = *

I guess that's really patronising, but I needed to make my point clear.

[QUOTE][code]print (int)0*; // = 0[/code][/QUOTE]

It still treats it as octal since it's preceded by '0' (Moonbat said that is used to indicate octal, and I believe him), so it is invalid as an integer and you get zero.

I just checked Wikipedia:

[I]"The prefix customarily used to represent an octal number is zero (e.g. 07*)."[/I]

I've never had to work with it much before, so I never knew.

[QUOTE][code]print (int)"0*"; // = *[/code][/QUOTE]

Explained above -- it discards the preceding zeroes.


[QUOTE][code]print (string)0*; // = 0[/code][/QUOTE]

Yeah, invalid octal.

[QUOTE][code]print (string)"0*"; // = *[/code][/QUOTE]

Decimal.