rfc:inconsistent-behaviors

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:inconsistent-behaviors [2014/02/05 21:44]
sanfordwhiteman Added notes about PHP numeroalphabetic behavior as unexceptional
rfc:inconsistent-behaviors [2021/03/27 14:31] (current)
ilutov Move to inactive
Line 4: Line 4:
   * Date: 2014-01-08   * Date: 2014-01-08
   * Author: Yasuo Ohgaki <yohgaki@php.net>   * Author: Yasuo Ohgaki <yohgaki@php.net>
-  * Status: Draft (or Under Discussion or Accepted or Declined)+  * Status: Inactive
   * First Published at: http://wiki.php.net/rfc/comparison_inconsistency   * First Published at: http://wiki.php.net/rfc/comparison_inconsistency
   * Renamed to: https://wiki.php.net/rfc/inconsistent-behaviors   * Renamed to: https://wiki.php.net/rfc/inconsistent-behaviors
Line 25: Line 25:
  
 Type juggling only works for INTEGER or HEX like strings. Type juggling only works for INTEGER or HEX like strings.
 +
 +Most problematic is HEX like strings being auto-coerced during
 +comparison, but using //different rules// from manual casting. That
 +is, ( 0x0A == "0x0A" ) is not treated as ( 0x0A == (int)"0x0A" ),
 +although "0x0A" //is// translated to a number.
 +
 +This despite http://us2.php.net/manual/en/language.operators.comparison.php, which
 +states clearly that for number-string comparison, we "Translate
 +strings and resources to numbers." While it is feasible that some
 +string patterns cannot be "translated" (OCTAL and BINARY) at all, once
 +a "translation" is attempted, it should follow the same rules as (int)
 +casting for the same string. It is hard to view it is anything but a
 +bug that it does not.
  
 === HEX === === HEX ===
Line 159: Line 172:
  
 Not only is this not a bug, it isn't even exceptional behavior on the Not only is this not a bug, it isn't even exceptional behavior on the
-modern web. A user who find this behavior surprising is likely+modern web. Users who find this behavior surprising are likely
 inexperienced with MySQL -- clearly PHP's partner in server-side inexperienced with MySQL -- clearly PHP's partner in server-side
 ubiquity as part of the dominant *AMP stack -- which has the exact ubiquity as part of the dominant *AMP stack -- which has the exact
 same rules for auto-coercion of "numeroalphabetic" strings in a same rules for auto-coercion of "numeroalphabetic" strings in a
-comparison context.+comparison context. 
  
 In MySQL (all supported versions): In MySQL (all supported versions):
Line 285: Line 298:
  
 https://wiki.php.net/rfc/base-convert https://wiki.php.net/rfc/base-convert
 +
 +
 +
 +==== filter_var ====
 +
 +https://bugs.php.net/bug.php?id=66682
 +
 +<code php>
 +var_dump(filter_var('01', FILTER_VALIDATE_INT));
 +var_dump(filter_var('01', FILTER_VALIDATE_FLOAT));
 +</code>
 +
 +<code>
 +bool(false)
 +double(1)
 +</code>
  
  
Line 303: Line 332:
  
 http://jp2.php.net/min http://jp2.php.net/min
 +
 +
  
  
rfc/inconsistent-behaviors.1391636652.txt.gz · Last modified: 2017/09/22 13:28 (external edit)