From: steve dot phpnet at softcorp dot us Operating system: Windows, Linux PHP version: 4.3.8 PHP Bug Type: *Compile Issues Bug description: Octal truncated and used at first invalid digit, no error, no warning
Description: ------------ Dear PHP gods... An invalid octal value of 08 or 09 is ignored starting with the first invalid digit (the 8 or the 9). The valid digits preceding the first invalid are taken resulting in octal 00. This behavior is fully documented (see "Example 10-2 Octal Wierdness" in the "Integers" section). This causes serious negative side-effects and is very easy to fall into. Plus, it is inconsistent. Other such coding errors with numerical constants are flagged as a PARSE ERROR. IMHO, coding 08 or 09 should produce a PARSE ERROR just like coding 0A or 0X0G does. The practical example where I encountered this error was with gmmktime. With several rows of gmmktime calls, I coded leading zeroes on the decimal arguments to make them line up in columns, not intending that they become octals. August (08) and September (09) were invalid octals and zero was used for the month instead. gmmktime did not flag month 00 as an error (gmmktime feature) and produced the wrong date. Observing very strange behavior and researching this, I found out why. IMHO this is a bug. Documenting this as an octal "feature" instead of rejecting the erroneous octals takes something away from the outstanding language that PHP is. Hope I'm not wasting your time... Most Respectfully... -----Steve Jackson Reproduce code: --------------- <?php print "--------------------------------------------- DECIMAL\n"; $x = 8; print "d=$x\n"; // GOOD $x = 9; print "d=$x\n"; // GOOD $x = A; print "d=$x\n"; // ASSUMED TO BE A STRING WITH LETTER 'A' print "--------------------------------------------- HEXADECIMAL\n"; $x = 0x0E; print "h=$x\n"; // GOOD $x = 0x0F; print "h=$x\n"; // GOOD //$x = 0x0G; print "h=$x\n"; // PRODUCES PARSE ERROR print "--------------------------------------------- OCTAL\n"; $x = 06; print "x=$x\n"; // GOOD $x = 07; print "x=$x\n"; // GOOD $x = 08; print "x=$x <<< SHOULD PRODUCE PARSE ERROR. ZERO USED. \n"; $x = 019; print "x=$x <<< SHOULD PRODUCE PARSE ERROR. ONE USED. \n"; //$x = 0A; print "x=$x\n"; // PRODUCES PARSE ERROR print "--------------------------------------------- PRACTICAL EXAMPLE\n"; print "Unintended result from gmmktime:" . "\n"; $date = gmmktime ( 0, 0, 0, 08, 01, 2004 ); // SHOULD BE PARSE ERROR print "date=$date" . "\n"; print gmdate( "n/j/Y H:i:s", $date ) . "\n"; ?> Expected result: ---------------- PARSE ERROR on the indicated lines. Actual result: -------------- Octal 08 and 019 were ignored. 00 and 01, respectively, were used instead without any warning or error at all. -- Edit bug report at http://bugs.php.net/?id=29676&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29676&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29676&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29676&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29676&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29676&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29676&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29676&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=29676&r=support Expected behavior: http://bugs.php.net/fix.php?id=29676&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=29676&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=29676&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29676&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29676&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29676&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29676&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=29676&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29676&r=float
