#41105 [NEW]: FILTER_FLAG_ALLOW_{HEX,OCTAL} do nothing

From: dohpaz at gmail dot com Operating system: Linux 2.6.18.1 PHP version: 5.2.1 PHP Bug Type: Filter related Bug description: FILTER_FLAG_ALLOW_{HEX,OCTAL} do nothing Description: ------------ The problem I am facing is that filter_var(), coupled with FILTER_FLAG_ALLOW_{HEX,OCTAL} flags, is not working as I would expect. I would expect that using either of those flags would only allow their respective notations. Instead, they pretty much do nothing. I can call filter_var() using the FILTER_VALIDATE_INT, and any combination of filter flags, and get the same exact results each time. This is deomonstrated below: 1. filter_var(42, FILTER_VALIDATE_INT): int(42) (Expected integer value 42) 2. filter_var(42, FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_HEX): int(42) (Expected boolean value FALSE) 3. filter_var(0x42, FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_HEX): int(66) (Expected integer value 66) 4. filter_var(0x42, FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_OCTAL): int(66) (Expected boolean value FALSE) So I guess my question is, what is the point of having these seperate flags that seemingly do nothing? Maybe this is a lack of _GOOD_ documentation in the PHP manual, but I would expect to be able to use filter_var() to distinguish between numbers using different bases. Afterall, 42 is not the same as 0x42, or 042. Finally, why is filter_var() just limited to three base systems? Wouldn't it make much more sense for there to be an option, perhaps called 'base', that would allow any arbitrary base (2, 13, 8, 16, etc) and validate the input on that? Reproduce code: --------------- 1. <?php var_dump(filter_var(42, FILTER_VALIDATE_INT)); ?> 2. <?php var_dump(filter_var(42, FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_HEX)); ?> 3. <?php var_dump(filter_var(0x42, FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_HEX)); ?> 4. <?php var_dump(filter_var(0x42, FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_OCTAL)); ?> Expected result: ---------------- 1. 42 (as expected) 2. FALSE (got 42 instead) 3. 66 (as expected) 4. FALSE (got 66 instead) Actual result: -------------- 1. 42 2. 42 3. 66 4. 66 -- Edit bug report at http://bugs.php.net/?id=41105&edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41105&r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41105&r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41105&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41105&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41105&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41105&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=41105&r=needscript Try newer version: http://bugs.php.net/fix.php?id=41105&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41105&r=support Expected behavior: http://bugs.php.net/fix.php?id=41105&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41105&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41105&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41105&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41105&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41105&r=dst IIS Stability: http://bugs.php.net/fix.php?id=41105&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41105&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41105&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41105&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=41105&r=mysqlcfg