rfc:comparison_inconsistency
no way to compare when less than two revisions

Differences

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


Previous revision
Next revision
rfc:comparison_inconsistency [2013/11/10 22:40] – [Function/Method] yohgaki
Line 1: Line 1:
  
 +====== PHP RFC: Existing comparison and conversion inconsistency  ======
 +  * Version: 0.1
 +  * Date: 2013-10-31
 +  * Author: Yasuo Ohgaki <yohgaki@php.net>
 +  * Status: Draft (or Under Discussion or Accepted or Declined)
 +  * First Published at: http://wiki.php.net/rfc/comparison_inconsistency
 +
 +This RFC is to discuss comparison and conversion inconsistencies in PHP. 
 +
 +===== Introduction =====
 +
 +There are number of in comparison and conversion inconsistencies.
 +
 +For example, 
 +  * https://bugs.php.net/bug.php?id=53104 reports comparison inconsistency in min() function.
 +
 +There are number issues of like this.
 +
 +Purpose of this RFC is fix inconsistency where it's feasible, otherwise document then fully if it's not documented already.
 +
 +===== Inconsistency =====
 +==== Conversion/comparison ====
 +
 +Type juggling only works for INTEGER or HEX like strings.
 +
 +=== HEX ===
 +Code
 +  var_dump(0x0A);
 +  var_dump("0x0A");
 +  var_dump((int)"0x0A");
 +  var_dump((float)"0x0A");
 +  var_dump(intval("0x0A"));
 +  var_dump(floatval("0x0A"));
 +
 +Output
 +  int(10)
 +  string(4) "0x0A"
 +  int(0)
 +  float(0)
 +  int(0)
 +  float(0)
 +
 +Code
 +  if (0x0A == '0x0A') {
 +    echo "0x0A == '0x0A'".PHP_EOL;
 +  }
 +  if (0x0A == "0x0A") {
 +    echo '0x0A == "0x0A"'.PHP_EOL;
 +  }
 +
 +Output
 +  0x0A == '0x0A'
 +  0x0A == "0x0A"
 +
 +
 +=== Octal ===
 +
 +Code
 +  var_dump(010);
 +  var_dump("010");
 +  var_dump((int)"010");
 +  var_dump((float)"010");
 +  var_dump(intval("010"));
 +  var_dump(floatval("010"));
 +
 +Output
 +  int(8)
 +  string(3) "010"
 +  int(10)
 +  float(10)
 +  int(10)
 +  float(10)
 +
 +CODE
 +  if (010 == '010') {
 +    echo "010 == '010'".PHP_EOL;
 +  }
 +  if (010 == "010") {
 +    echo '010 == "010"'.PHP_EOL;
 +  }
 +
 +OUTPUT
 +  (NONE)
 +
 +
 +=== BINARY ===
 +
 +Code
 +  var_dump(0b110);
 +  var_dump("0b110");
 +  var_dump((int)"0b110");
 +  var_dump((float)"0b110");
 +  var_dump(intval("0b110"));
 +  var_dump(floatval("0b110"));
 +
 +Output
 +  int(6)
 +  string(5) "0b110"
 +  int(0)
 +  float(0)
 +  int(0)
 +  float(0)
 +
 +CODE
 +  if (0b010 == '0b010') {
 +    echo "0b010 == '0b010'".PHP_EOL;
 +  }
 +  if (0b010 == "0b010") {
 +    echo '010 == "010"'.PHP_EOL;
 +  }
 +
 +OUTPUT
 +  (NONE)
 +
 +==== Function/Method ====
 +
 +=== min() function ===
 +
 +https://bugs.php.net/bug.php?id=53104
 +
 +This is not a bug. If one of operand is BOOL(or NULL), both operands are converted to BOOL and evaluated as BOOL. It may be good idea that document this behavior in min() manual.
 +
 +=== Return value of wrong internal function/method parameters ===
 +
 +If not all, almost all functions return NULL when required function parameter is missing or wrong type. However, almost all functions return FALSE when they have errors.
 +
 +The manual has document for this behavior
 +http://www.php.net/manual/en/functions.internal.php
 +
 +  Note: If the parameters given to a function are not what it expects, such as passing an array 
 +  where a string is expected, the return value of the function is undefined. In this case it will 
 +  likely return NULL but this is just a convention, and cannot be relied upon.
 +
 +This behavior could be cause of bug in scripts. For instance,
 +
 +  if (FALSE === some_func($wrong_parameter)) {
 +     // Error happend!
 +  } else {
 +     // OK to go
 +  }
 +
 +Users should not rely on return value as it may return NULL for wrong parameters. Users should rely on error/exception handler for such case as internal functions raise E_WARNING in this case. (If there are function that does not raise error, it is subject to be fixed.)
 +
 +It may be good to add use of error/exception handler as best practice in the manual.
 +http://www.php.net/manual/en/functions.internal.php
 +
 +There are bug reports that complain return value inconsistency. The document could be improved with more explanations.
 +
 +== Related Bug Reports ==
 +  * https://bugs.php.net/bug.php?id=60338 (Returns value for wrong key())
 +  * https://bugs.php.net/bug.php?id=64860 (returns NULL for wrong file parameter)
 +  * https://bugs.php.net/bug.php?id=65986 (returns NULL for wrong parameter)
 +  * https://bugs.php.net/bug.php?id=65604 (returns NULL for too huge parameter, probably)
 +  * https://bugs.php.net/bug.php?id=59225 (returns NULL when it should return FALSE? when server is not accessible?)
 +  * https://bugs.php.net/bug.php?id=65910 (returns NULL for wrong parameter)
 +  * https://bugs.php.net/bug.php?id=62492 (returns NULL for wrong parameter)
 +  * https://bugs.php.net/bug.php?id=44049 (returns NULL for wrong parameter by mistake? Expecting prepared query params?)
 +  * https://bugs.php.net/bug.php?id=64140 (returns NULL for wrong parameter without error/exception?)
 +
 +Bug reports are not verified carefully. Removing wrong one, adding proper one is appreciated.
 +
 +== Developer Guideline ==
 +
 +  * Internal function/method should raise error(or exception) for invalid parameters. (parse parameters function does this)
 +  * Internal function/method is better to return NULL for invalid parameters as most functions do.
 +  * Internal function/method is better to return FALSE for other errors.
 +
 +== User Guideline ==
 +
 +  * User should not rely return value only for failure condition, but should rely error/exception handler for failure also.
 +
 +===== Proposal =====
 +
 +Not yet.
 +
 +===== Backward Incompatible Changes =====
 +
 +Not yet.
 +
 +===== Proposed PHP Version(s) =====
 +
 +PHP 6.0 probably.
 +
 +===== Impact to Existing Extensions =====
 +
 +Not yet.
 +
 +===== New Constants =====
 +
 +Not yet.
 +
 +===== php.ini Defaults =====
 +
 +If there are any php.ini settings then list:
 +  * hardcoded default values
 +  * php.ini-development values
 +  * php.ini-production values
 +
 +Not yet.
 +
 +===== Open Issues =====
 +
 +Make sure there are no open issues when the vote starts!
 +
 +===== Unaffected PHP Functionality =====
 +
 +List existing areas/features of PHP that will not be changed by the RFC.
 +
 +This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.
 +
 +===== Future Scope =====
 +
 +This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC.
 +
 +===== Proposed Voting Choices =====
 +
 +Include these so readers know where you are heading and can discuss the proposed voting options.
 +
 +===== Patches and Tests =====
 +
 +Links to any external patches and tests go here.
 +
 +If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.
 +
 +Make it clear if the patch is intended to be the final patch, or is just a prototype.
 +
 +===== Implementation =====
 +
 +After the project is implemented, this section should contain 
 +  - the version(s) it was merged to
 +  - a link to the git commit(s)
 +  - a link to the PHP manual entry for the feature
 +
 +===== References =====
 +
 +Links to external references, discussions or RFCs
 +
 +===== Rejected Features =====
 +
 +Keep this updated with features that were discussed on the mail lists.
 +
 +===== ChangeLog =====
 +
 +  * 2013/10/31 - Initial version.