php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #29676 Octal truncated and used at first invalid digit, no error, no warning
Submitted: 2004-08-14 14:24 UTC Modified: 2004-08-16 08:47 UTC
Votes:8
Avg. Score:4.5 ± 1.3
Reproduced:6 of 6 (100.0%)
Same Version:2 (33.3%)
Same OS:4 (66.7%)
From: steve dot phpnet at softcorp dot us Assigned:
Status: Wont fix Package: *Compile Issues
PHP Version: 4.3.8 OS: Windows, Linux
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2004-08-14 14:24 UTC] steve dot phpnet at softcorp dot us
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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-08-16 08:47 UTC] derick@php.net
I once looked into fixed this, but this would slow down PHP dramatically in all cases where numbers are used inside scripts. Hence it's not worthwhile to "fix" this.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 20 02:01:29 2024 UTC