Req #43304 [Com]: Casting During Comparison
Edit report at https://bugs.php.net/bug.php?id=43304&edit=1 ID: 43304 Comment by: delphists at apollo dot lv Reported by:ken at smallboxsoftware dot net Summary:Casting During Comparison Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: ALL PHP Version:5.2.5 Block user comment: N Private report: N New Comment: >From docs: [quote] If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically. [/quote] Want to be strict, when comparing? Then use strict operators... Previous Comments: [2012-01-16 14:29:07] michael dot kluge at wundermedia dot de No comments from any PHP devs yet? Well I strongly disagree with the current implementation. >From PHP-Docs: $a === $b Identical TRUE if $a is equal to $b, and they are of the same type. This is the correct definition of the === operator. An so it should work like that definition: So $a = "001234"; $b = "1234"; $a == $b should be equal to $a === $b (both should be false) as both variables hold the same type and from the above definition those expressions should be equal: $a === $b ($a == $b && typeof($a)==typeof($b)) So if (typeof($a)==typeof($b)) is true, $a===$b should be identical to $a==$b. If comparing two variables of the same type in NO case any type-conversion should be applied! If you need conversions in those cases these should be explicitly noted as e.g.: intval($a) == intval($b) Adding special exceptions to the general definition doesn't make much sense in my eyes; it just makes the base definition wrong in certain circumstances and leads to unexpected behaviour in certain cases (see comment from kissifrot). We stumbled upon this when comparing certain product ids in use by one of our customers, just being different in the leading zeros. (So id "001" is another product than "01" ==> therefore using strings; please don't ask why, as I don't know what reasons might have caused these strange ids) delphists said that "there are also lots of cases when numerical strings have to be compared as integers". I agree with that, but in those cases the developer should convert the types manually. Also the example with the database should, in my opinion, be implemented differently: The model should return integers for integer-typed database fields and not strings. On the other hand if you expect input parameters containing integer values these could also be converted to integers, which can be easily done in the validity checks of the parameters. IMHO, despite of PHP trying to make type-conversions transparent to the developer, the developer should in any case keep in mind, that PHP is not typeless and respect the types accordingly. And "0123" and "123" are definitely NOT logically equal in any case! I think the weird concept of "numerical strings" should be dropped. -------- [2011-03-11 09:43:13] delphists at apollo dot lv Sorry for digging up this bug report, but it's still opened, so I don't think that digging it up should be a problem. I agree with kissifrot about specific case - both values convert to "(int)2147483647", at least on 32bit system, which is nowhere near to "11000198358". Though, I can't agree with drm. There is a reason for having two types of comparisons - if you are sure that you don't need values to be converted, just use strict comparison. I agree that there are cases when numerical strings need to be compared as strings, but there are also lots of cases when numerical strings have to be compared as integers. For example, some functions that return data from DB, return integers as strings, which may be compared to data from browser, which by default is also string, but comparison needs to work like if they were numbers. [2011-02-17 08:58:37] kissifrot at gmail dot com I agree with that, for example if I have $ric1 = '11000198358'; $ric2 = '11000198455'; var_dump($ric1 == $ric2) should return false, not true, just because it's logical. But the current behavior makes PHP somewhat unreliable :( [2008-09-06 23:49:58] drm at melp dot nl Though documented (http://www.php.net/language.operators, quote "If you compare two numerical strings, they are compared as integers."), this is indeed unexpected behaviour (and thus a bug) This bug will probab
[PHP-BUG] Bug #52464 [NEW]: spl_autoload_register() can use protected/private methods if called from class
From:
Operating system: Windows 7, Linux Slackware
PHP version: 5.3.3
Package: SPL related
Bug Type: Bug
Bug description:spl_autoload_register() can use protected/private methods if
called from class
Description:
If spl_autoload_register() is called from class method, SPL autoloader can
use private and protected methods, although SPL is not a part of this
class. It works well if spl_autoload_register() is called from somewhere
else.
Test script:
---
__construct()
#2 {main}
thrown in test.php on line 5
Actual result:
--
CallbackTest::publicCallback
CallbackTest::protectedCallback
CallbackTest::privateCallback
PHP Fatal error: Class 'AutoloadTest' not found in test.php on line 19
--
Edit bug report at http://bugs.php.net/bug.php?id=52464&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52464&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52464&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52464&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52464&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52464&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52464&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52464&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52464&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52464&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52464&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52464&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52464&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52464&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52464&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52464&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=52464&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52464&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52464&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52464&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52464&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52464&r=mysqlcfg
Bug #53949 [Com]: Rounding error
Edit report at http://bugs.php.net/bug.php?id=53949&edit=1 ID: 53949 Comment by: delphists at apollo dot lv Reported by:pleszczynski at zubi dot pl Summary:Rounding error Status: Open Type: Bug Package:Unknown/Other Function Operating System: Linux PHP Version:5.2.17 Block user comment: N Private report: N New Comment: Getting invalid results for values between 1048576.505 and 1342176.505: Result: Got correct result with n = 1048574.505 Got correct result with n = 1048575.505 Got correct result with n = 1342177.505 Got correct result with n = 1342178.505 Previous Comments: [2011-02-07 14:13:17] pleszczynski at zubi dot pl Description: PHP 5.2.13 & 5.2.17 both have this weird errors in rounding function. This happens quite often, I can supply other numbers as well. Test script: --- http://bugs.php.net/bug.php?id=53949&edit=1
Req #43304 [Com]: Casting During Comparison
Edit report at http://bugs.php.net/bug.php?id=43304&edit=1
ID: 43304
Comment by: delphists at apollo dot lv
Reported by:ken at smallboxsoftware dot net
Summary:Casting During Comparison
Status: Open
Type: Feature/Change Request
Package:Feature/Change Request
Operating System: ALL
PHP Version:5.2.5
Block user comment: N
Private report: N
New Comment:
Sorry for digging up this bug report, but it's still opened, so I don't
think that digging it up should be a problem.
I agree with kissifrot about specific case - both values convert to
"(int)2147483647", at least on 32bit system, which is nowhere near to
"11000198358".
Though, I can't agree with drm. There is a reason for having two types
of comparisons - if you are sure that you don't need values to be
converted, just use strict comparison.
I agree that there are cases when numerical strings need to be compared
as strings, but there are also lots of cases when numerical strings have
to be compared as integers. For example, some functions that return data
from DB, return integers as strings, which may be compared to data from
browser, which by default is also string, but comparison needs to work
like if they were numbers.
Previous Comments:
[2011-02-17 08:58:37] kissifrot at gmail dot com
I agree with that, for example if I have
$ric1 = '11000198358';
$ric2 = '11000198455';
var_dump($ric1 == $ric2)
should return false, not true, just because it's logical.
But the current behavior makes PHP somewhat unreliable :(
[2008-09-06 23:49:58] drm at melp dot nl
Though documented (http://www.php.net/language.operators, quote "If you
compare two numerical strings, they are compared as integers."), this is
indeed unexpected behaviour (and thus a bug)
This bug will probably be closed and denoted as "sorry, documented
feature", but I think this is really a candidate for revision in any
next major PHP version.
Comparison should always feel intuitive, and PHP has made the move
towards more "secure" defaults. This falls (imo) under the same
category. Please witness following example.
client side code:
No selection
whatever
selection
(...)
server side code:
if ( $_GET['selection'] == 0 ) {
echo 'Please make a selection!';
} else {
// process request
}
Though the example does not imply any security issues, they are not
unimaginable. Please reconsider the behaviour of the comparison
operator.
My suggestion:
Implement (and document!) the following:
Any left side of the comparison is only cast to number if the right side
doesn't fail to. Casting to number is considered successful, if and only
if the string would syntactically be a number in the PHP
Therefore, the string should match the following:
http://php.net/language.types.integer
http://php.net/language.types.float
[At both pages, see the "formal" definition of both types.]
In any OTHER case, the comparison should act as follows:
If ANY of the sides is of a string type (and of course fails to cast to
number), the other side is cast to string, causing the types to follow
these rules:
integer: the string representation of the integer (e.g. "0", "-4" or
"123")
float: the string representation of the floating point number,
represented in one and only one particular format, preferably just the
%.f format.
boolean: cast to integer, cast to string (so true becomes 1, becomes
"1"; false becomes 0 becomes "0")
array: "array" causing a notice
object: "object" causing a notice, or calling the __toString method if
defined.
The oppposing problem is a non-generic way of handling any other
comparison. As a rule, we could state that any other comparison -if both
sides of different type- is handled the way it is in the current PHP
version. If they are of the same type, the == operator should act the
same as the === operator.
This is, as i am very sure, easily realized.
Please do not hesitate to ask me any questions through mail.
[2007-11-15 16:27:02] ken at smallboxsoftware dot net
Description:
Casting during comparison should only happen if values of different
types are being compared.
For example: "42" == "+42" should not return true.
This result is not very intuitive and probably leads to a number of
subtle errors in various scripts.
Reproduce code:
---
";
echo "Should Return False:".((string) "400" == (string) "+400")."";
echo "Does Return False:".("400" === "+400")."";
?>
--
Edit this bug report at http://bugs.php.net/bug.php?id=43304&edit=1
[PHP-BUG] Req #54667 [NEW]: $offset parameter for md5_file() and sha1_file()
From: Operating system: PHP version: Irrelevant Package: *Encryption and hash functions Bug Type: Feature/Change Request Bug description:$offset parameter for md5_file() and sha1_file() Description: There are some functions that calculate hash from a file, e.g., md5_file() and sha1_file(), but they work only for whole files. There's also a function (or a language construct?) __halt_compiler(), which is useful for making "installers", as it allows to mix PHP code and binary data (e.g., compressed archive) in a single file. To make sure that whole "installer" is correctly downloaded, it would be worth to validate checksum of binary data by comparing it with value of checksum that is stored in PHP code part (i.e., before __halt_compiler()). Currently, checksum of binary data may be calculated by fully loading binary data and calling md5() or sha1() on a string. It is not a problem for smaller installers, but if installer is larger (e.g., because of having lots of images in it), it might require too much memory to be loaded into a string. In this case, it would be handy to use md5_file() or sha1_file() with 3rd parameter - $offset, something like md5_file($filename, false, __COMPILER_HALT_OFFSET__). Any chance to see it implemented some day? -- Edit bug report at http://bugs.php.net/bug.php?id=54667&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=54667&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=54667&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=54667&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=54667&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=54667&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=54667&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=54667&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=54667&r=needscript Try newer version: http://bugs.php.net/fix.php?id=54667&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=54667&r=support Expected behavior: http://bugs.php.net/fix.php?id=54667&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=54667&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=54667&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=54667&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54667&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=54667&r=dst IIS Stability: http://bugs.php.net/fix.php?id=54667&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=54667&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=54667&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=54667&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=54667&r=mysqlcfg
