![]() A 2/3 majority is required.Superglobals $GLOBALS $_SERVER $_REQUEST $_POST $_GET PHP RegEx This inconsistency is being addressed by the saner numeric strings RFC. Before | After | Type var_dump ( 42 = " 42" ) // true | true | well-formed var_dump ( 42 = "42 " ) // true | false | non well-formed (*) var_dump ( 42 = "42abc" ) // true | false | non well-formed var_dump ( 42 = "abc42" ) // false | false | non-numeric var_dump ( 0 = "abc42" ) // true | false | non-numeric // (*) Becomes well-formed if saner numeric strings RFC passesĪ notable asymmetry under the new semantics is that " 42" and "42 " compare differently. Before *and* after this RFC var_dump ( "42" = "000042" ) // true var_dump ( "42" = "42.0" ) // true var_dump ( "42.0" = "+42.0E0" ) // true var_dump ( "0" = "0e214987142012" ) // trueĭifferent comparison semantics only appear once either non well-formed or non-numeric strings are involved: It should be noted that this is also consistent with performing the same (non-strict) comparisons in string form: This means that not only are trivial cases like 42 = "42" true, but also cases where the numbers are given in different formats: Under this proposal well-formed numeric strings have exactly the same comparison semantics as previously. A non well-formed numeric string may have additional trailing characters. While a precise definition is given in the language specification, a well-formed numeric string may be briefly described as optional whitespace followed by a decimal integer or floating-point literal. This description of the comparison semantics is slightly simplified, and the detailed rules will be outlined in the following, but it should give an intuitive understanding of the new rules and provide a motivation for why they were chosen. Compare the above table with the following results for string to string comparisons (which are not changed by this RFC): 0 = "0" | true | true 0 = "0.0" | true | true 0 = "foo" | true | false 0 = "" | true | false 42 = " 42" | true | true 42 = "42foo" | true | falseĪn alternative way to view these comparison semantics is that the number operand is cast to a string, and the strings are then compared using the non-strict “smart” string comparison algorithm. The following table shows how the result of some simple comparisons changes (or doesn't change) under this RFC: ![]() ![]() Otherwise, convert the number to string and use a string comparison. This RFC intends to give string to number comparisons a more reasonable behavior: When comparing to a numeric string, use a number comparison (same as now). Unfortunately, while the idea of non-strict comparisons has some merit, their current semantics are blatantly wrong in some cases and thus greatly limit the overall usefulness of non-strict comparisons. Additionally some constructs (such as switch) only support non-strict comparison natively. string array keys may be converted to integers). Considering 42 and "42" as the same value is useful in many contexts, in part also due to the implicit conversions performed by PHP (e.g. This is an unfortunate state of affairs, because the concept of non-strict comparisons is not without value in a language like PHP, which commonly deals with mixtures of numbers in both plain and stringified form. $validValues = $value = 0 var_dump ( in_array ( $value, $validValues ) ) // bool(true) WTF? Quite often this is encountered in cases where the comparison is implicit, such as in_array() or switch statements. The single largest source of bugs is likely the fact that 0 = "foobar" returns true. The current dogma in the PHP world is that non-strict comparisons should always be avoided, because their conversion semantics are rarely desirable and can easily lead to bugs or even security issues. Strict comparison compares objects by object identity, while non-strict comparison compares their values. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |