[PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
ID: 9186
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Closed
Status: Analyzed
Bug Type: Documentation problem
Assigned To:
Comments:
Ok, it should remain open as a documentation problem...
Previous Comments:
---
[2001-02-15 04:31:01] [EMAIL PROTECTED]
This is a defined behavior (and does have strong reasons). It's not a bug.
If you're interested in a byte-by-byte string comparison, you should use strcmp().
---
[2001-02-09 11:10:17] [EMAIL PROTECTED]
Incorrectly flagged as bogus.
---
[2001-02-09 10:59:10] [EMAIL PROTECTED]
I think there is no reason to convert any type if both
operands of the comparision are of the same type. It costs
time and it's completely not necessary. This is a bug.
I can not see any description of this behavior in the
manual. The string type section descibes only what is
happen if a string is converted.
---
[2001-02-09 10:27:46] [EMAIL PROTECTED]
Actually, this is a feature - it is described in the manual. Strings that look like
numbers are converted to numbers. Large numbers - like the ones below may not convert
perfectly from a string to a number. Review the manual section on PHP types in
general and strings in particular
(http://uk.php.net/manual/en/language.types.string.php)
While this is a relatively subtle bug, you can ensure that you are dealing with
strings by quoting the variables being compared or by using the === operator. This
behavior is exploited quite often in PHP scripts. However, perhaps it would be nice
if PHP generated an notice level error when it occured so that users have some
recourse when it happens unexpectedly.
If you feel strongly about this, propose it to the developers as a feature request.
Post your request on the [EMAIL PROTECTED] list (sub at
[EMAIL PROTECTED]) - if you get no response, be polite but persistant. :)
---
[2001-02-09 03:25:24] [EMAIL PROTECTED]
First the test script:
?
$a = '012345678901234567';
$b = '012345678901234568';
echo ($a == $b) ? "a equal bn" : "a not equal bn";
echo ($a === $b) ? "a equal bn" : "a not equal bn";
printf ("as string: a=%s b=%sn", $a, $b);
printf ("as float: a=%.0f b=%.0fn", $a, $b);
printf ("as int: a=%d b=%dn", $a, $b);
?
and its output:
a equal b
a not equal b
as string: a=012345678901234567 b=012345678901234568
as float: a=12345678901234567 b=12345678901234567
as int: a=2147483647 b=2147483647
Zend trys to convert the arguments to numbers if both
arguments are strings. This is not good and its not a
feature.
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9186edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
ID: 9186 User Update by: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Description: string compare with "==" does not work correctly Ok, I accept this. But I don't think that is a good idea to compare apples with pears with the answer 'yes they are fruit' without any warning. Previous Comments: --- [2001-02-15 04:32:00] [EMAIL PROTECTED] Ok, it should remain open as a documentation problem... --- [2001-02-15 04:31:01] [EMAIL PROTECTED] This is a defined behavior (and does have strong reasons). It's not a bug. If you're interested in a byte-by-byte string comparison, you should use strcmp(). --- [2001-02-09 11:10:17] [EMAIL PROTECTED] Incorrectly flagged as bogus. --- [2001-02-09 10:59:10] [EMAIL PROTECTED] I think there is no reason to convert any type if both operands of the comparision are of the same type. It costs time and it's completely not necessary. This is a bug. I can not see any description of this behavior in the manual. The string type section descibes only what is happen if a string is converted. --- [2001-02-09 10:27:46] [EMAIL PROTECTED] Actually, this is a feature - it is described in the manual. Strings that look like numbers are converted to numbers. Large numbers - like the ones below may not convert perfectly from a string to a number. Review the manual section on PHP types in general and strings in particular (http://uk.php.net/manual/en/language.types.string.php) While this is a relatively subtle bug, you can ensure that you are dealing with strings by quoting the variables being compared or by using the === operator. This behavior is exploited quite often in PHP scripts. However, perhaps it would be nice if PHP generated an notice level error when it occured so that users have some recourse when it happens unexpectedly. If you feel strongly about this, propose it to the developers as a feature request. Post your request on the [EMAIL PROTECTED] list (sub at [EMAIL PROTECTED]) - if you get no response, be polite but persistant. :) --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=9186 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
ID: 9186 Updated by: hholzgra Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Assigned To: Comments: this autoconversion is usefull when dealing with html form input (for which php is used every once in a while afaik :) as html has no numric input elements, just text maybe it would make sense to have this behaviour configurable in the ini file, but i'm afraid that this would only increase the WTF factor even more Previous Comments: --- [2001-02-15 05:07:35] [EMAIL PROTECTED] Ok, I accept this. But I don't think that is a good idea to compare apples with pears with the answer 'yes they are fruit' without any warning. --- [2001-02-15 04:32:00] [EMAIL PROTECTED] Ok, it should remain open as a documentation problem... --- [2001-02-15 04:31:01] [EMAIL PROTECTED] This is a defined behavior (and does have strong reasons). It's not a bug. If you're interested in a byte-by-byte string comparison, you should use strcmp(). --- [2001-02-09 11:10:17] [EMAIL PROTECTED] Incorrectly flagged as bogus. --- [2001-02-09 10:59:10] [EMAIL PROTECTED] I think there is no reason to convert any type if both operands of the comparision are of the same type. It costs time and it's completely not necessary. This is a bug. I can not see any description of this behavior in the manual. The string type section descibes only what is happen if a string is converted. --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9186edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
ID: 9186 User Update by: [EMAIL PROTECTED] Status: Analyzed Bug Type: Documentation problem Description: string compare with "==" does not work correctly The conversation is useful. I know this because HTML form parameters, MySQL result sets are strings even if they are represent numbers. But there some cases for which the conversation is not useful. If the result is MAXINT, MININT or NaN, it would be better not converting the operands and making a string comparision. A warning message whould be also useful. Previous Comments: --- [2001-02-15 05:25:09] [EMAIL PROTECTED] this autoconversion is usefull when dealing with html form input (for which php is used every once in a while afaik :) as html has no numric input elements, just text maybe it would make sense to have this behaviour configurable in the ini file, but i'm afraid that this would only increase the WTF factor even more --- [2001-02-15 05:07:35] [EMAIL PROTECTED] Ok, I accept this. But I don't think that is a good idea to compare apples with pears with the answer 'yes they are fruit' without any warning. --- [2001-02-15 04:32:00] [EMAIL PROTECTED] Ok, it should remain open as a documentation problem... --- [2001-02-15 04:31:01] [EMAIL PROTECTED] This is a defined behavior (and does have strong reasons). It's not a bug. If you're interested in a byte-by-byte string comparison, you should use strcmp(). --- [2001-02-09 11:10:17] [EMAIL PROTECTED] Incorrectly flagged as bogus. --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=9186 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
ID: 9186
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Analyzed
Old-Bug Type: Scripting Engine problem
Bug Type: Documentation problem
Assigned To:
Comments:
Previous Comments:
---
[2001-02-09 10:59:10] [EMAIL PROTECTED]
I think there is no reason to convert any type if both
operands of the comparision are of the same type. It costs
time and it's completely not necessary. This is a bug.
I can not see any description of this behavior in the
manual. The string type section descibes only what is
happen if a string is converted.
---
[2001-02-09 10:27:46] [EMAIL PROTECTED]
Actually, this is a feature - it is described in the manual. Strings that look like
numbers are converted to numbers. Large numbers - like the ones below may not convert
perfectly from a string to a number. Review the manual section on PHP types in
general and strings in particular
(http://uk.php.net/manual/en/language.types.string.php)
While this is a relatively subtle bug, you can ensure that you are dealing with
strings by quoting the variables being compared or by using the === operator. This
behavior is exploited quite often in PHP scripts. However, perhaps it would be nice
if PHP generated an notice level error when it occured so that users have some
recourse when it happens unexpectedly.
If you feel strongly about this, propose it to the developers as a feature request.
Post your request on the [EMAIL PROTECTED] list (sub at
[EMAIL PROTECTED]) - if you get no response, be polite but persistant. :)
---
[2001-02-09 03:25:24] [EMAIL PROTECTED]
First the test script:
?
$a = '012345678901234567';
$b = '012345678901234568';
echo ($a == $b) ? "a equal bn" : "a not equal bn";
echo ($a === $b) ? "a equal bn" : "a not equal bn";
printf ("as string: a=%s b=%sn", $a, $b);
printf ("as float: a=%.0f b=%.0fn", $a, $b);
printf ("as int: a=%d b=%dn", $a, $b);
?
and its output:
a equal b
a not equal b
as string: a=012345678901234567 b=012345678901234568
as float: a=12345678901234567 b=12345678901234567
as int: a=2147483647 b=2147483647
Zend trys to convert the arguments to numbers if both
arguments are strings. This is not good and its not a
feature.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9186edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
ID: 9186
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Bogus
Bug Type: Scripting Engine problem
Assigned To:
Comments:
Actually, this is a feature - it is described in the manual. Strings that look like
numbers are converted to numbers. Large numbers - like the ones below may not convert
perfectly from a string to a number. Review the manual section on PHP types in
general and strings in particular
(http://uk.php.net/manual/en/language.types.string.php)
While this is a relatively subtle bug, you can ensure that you are dealing with
strings by quoting the variables being compared or by using the === operator. This
behavior is exploited quite often in PHP scripts. However, perhaps it would be nice
if PHP generated an notice level error when it occured so that users have some
recourse when it happens unexpectedly.
If you feel strongly about this, propose it to the developers as a feature request.
Post your request on the [EMAIL PROTECTED] list (sub at
[EMAIL PROTECTED]) - if you get no response, be polite but persistant. :)
Previous Comments:
---
[2001-02-09 03:25:24] [EMAIL PROTECTED]
First the test script:
?
$a = '012345678901234567';
$b = '012345678901234568';
echo ($a == $b) ? "a equal bn" : "a not equal bn";
echo ($a === $b) ? "a equal bn" : "a not equal bn";
printf ("as string: a=%s b=%sn", $a, $b);
printf ("as float: a=%.0f b=%.0fn", $a, $b);
printf ("as int: a=%d b=%dn", $a, $b);
?
and its output:
a equal b
a not equal b
as string: a=012345678901234567 b=012345678901234568
as float: a=12345678901234567 b=12345678901234567
as int: a=2147483647 b=2147483647
Zend trys to convert the arguments to numbers if both
arguments are strings. This is not good and its not a
feature.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9186edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
ID: 9186
User Update by: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Description: string compare with "==" does not work correctly
I think there is no reason to convert any type if both
operands of the comparision are of the same type. It costs
time and it's completely not necessary. This is a bug.
I can not see any description of this behavior in the
manual. The string type section descibes only what is
happen if a string is converted.
Previous Comments:
---
[2001-02-09 10:27:46] [EMAIL PROTECTED]
Actually, this is a feature - it is described in the manual. Strings that look like
numbers are converted to numbers. Large numbers - like the ones below may not convert
perfectly from a string to a number. Review the manual section on PHP types in
general and strings in particular
(http://uk.php.net/manual/en/language.types.string.php)
While this is a relatively subtle bug, you can ensure that you are dealing with
strings by quoting the variables being compared or by using the === operator. This
behavior is exploited quite often in PHP scripts. However, perhaps it would be nice
if PHP generated an notice level error when it occured so that users have some
recourse when it happens unexpectedly.
If you feel strongly about this, propose it to the developers as a feature request.
Post your request on the [EMAIL PROTECTED] list (sub at
[EMAIL PROTECTED]) - if you get no response, be polite but persistant. :)
---
[2001-02-09 03:25:24] [EMAIL PROTECTED]
First the test script:
?
$a = '012345678901234567';
$b = '012345678901234568';
echo ($a == $b) ? "a equal bn" : "a not equal bn";
echo ($a === $b) ? "a equal bn" : "a not equal bn";
printf ("as string: a=%s b=%sn", $a, $b);
printf ("as float: a=%.0f b=%.0fn", $a, $b);
printf ("as int: a=%d b=%dn", $a, $b);
?
and its output:
a equal b
a not equal b
as string: a=012345678901234567 b=012345678901234568
as float: a=12345678901234567 b=12345678901234567
as int: a=2147483647 b=2147483647
Zend trys to convert the arguments to numbers if both
arguments are strings. This is not good and its not a
feature.
---
Full Bug description available at: http://bugs.php.net/?id=9186
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
ID: 9186
Updated by: zak
Reported By: [EMAIL PROTECTED]
Old-Status: Bogus
Status: Open
Bug Type: Scripting Engine problem
Assigned To:
Comments:
Incorrectly flagged as bogus.
Previous Comments:
---
[2001-02-09 10:59:10] [EMAIL PROTECTED]
I think there is no reason to convert any type if both
operands of the comparision are of the same type. It costs
time and it's completely not necessary. This is a bug.
I can not see any description of this behavior in the
manual. The string type section descibes only what is
happen if a string is converted.
---
[2001-02-09 10:27:46] [EMAIL PROTECTED]
Actually, this is a feature - it is described in the manual. Strings that look like
numbers are converted to numbers. Large numbers - like the ones below may not convert
perfectly from a string to a number. Review the manual section on PHP types in
general and strings in particular
(http://uk.php.net/manual/en/language.types.string.php)
While this is a relatively subtle bug, you can ensure that you are dealing with
strings by quoting the variables being compared or by using the === operator. This
behavior is exploited quite often in PHP scripts. However, perhaps it would be nice
if PHP generated an notice level error when it occured so that users have some
recourse when it happens unexpectedly.
If you feel strongly about this, propose it to the developers as a feature request.
Post your request on the [EMAIL PROTECTED] list (sub at
[EMAIL PROTECTED]) - if you get no response, be polite but persistant. :)
---
[2001-02-09 03:25:24] [EMAIL PROTECTED]
First the test script:
?
$a = '012345678901234567';
$b = '012345678901234568';
echo ($a == $b) ? "a equal bn" : "a not equal bn";
echo ($a === $b) ? "a equal bn" : "a not equal bn";
printf ("as string: a=%s b=%sn", $a, $b);
printf ("as float: a=%.0f b=%.0fn", $a, $b);
printf ("as int: a=%d b=%dn", $a, $b);
?
and its output:
a equal b
a not equal b
as string: a=012345678901234567 b=012345678901234568
as float: a=12345678901234567 b=12345678901234567
as int: a=2147483647 b=2147483647
Zend trys to convert the arguments to numbers if both
arguments are strings. This is not good and its not a
feature.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9186edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
Alan van den Bosch wrote: [snip] This issue arises from the loose typing in PHP with the introduction of first class boolean type (the true and false keywords), from my understanding the sematics being applied here are as follows (poetic license applied liberally); == is (has become?) a boolean logic operator, dealing in terms of 'true' and 'false' values, so its terms are type cast to either 'true' or 'false'. When applied to strings, a 'false' string is zero length or contains '0', all other strings are 'true'. [please dont ask 'what if the string is NULL... ;-)] If you dont want your terms to be treated as (type cast to) boolean values use the strict equallity operator === I can not see any description of this behavior in the manual. The string type section descibes only what is happen if a string is converted. The manual doesnt seem very clear on this at all, but == behaves something like ^(A xor B) While I certainly appreciate the support :) - I am not sure that this is a correct appraisal of the situation. We should take a look at the source code and see what it actually does. My impression is that it should cast the values as strings and then compare the strings. --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
At 17:59 9/2/2001, [EMAIL PROTECTED] wrote: ID: 9186 User Update by: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Description: string compare with "==" does not work correctly I think there is no reason to convert any type if both operands of the comparision are of the same type. It costs time and it's completely not necessary. This is a bug. No, it's not a bug. It's definitely an intended behavior. PHP does it's best to do the 'right thing' in the most common cases. Because of the way it works, effectively, comparing strings that 'look like numbers' as if they were numbers makes life much, much easier. If you want to enforce a string comparison, use strcmp(). Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
At 19:34 9/2/2001, Hartmut Holzgraefe wrote: Alan van den Bosch wrote: == is (has become?) a boolean logic operator, dealing in terms of 'true' and 'false' values, so its terms are type cast to either 'true' or 'false'. When applied to strings, a 'false' string is zero length or contains '0', all other strings are 'true'. the result of == is boolean, not the arguments expected behaviour could be: if left-hand-type != right-hand-type convert right-hand-argument to left-hand type compare left-hand-argument to possibly converted right-hand-argument There's no (and shouldn't be any) significance in the order of the arguments. additionaly, IMHO, as php has to deal with html forms a lot and html has no input type=numeric there are a lot of places where a string that qualifies as is_numeric is silently treated as a numeric argument Right, that's why PHP automatically compares two string-like strings as if they were numbers. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
Zeev Suraski wrote: At 17:59 9/2/2001, [EMAIL PROTECTED] wrote: ID: 9186 User Update by: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Description: string compare with "==" does not work correctly I think there is no reason to convert any type if both operands of the comparision are of the same type. It costs time and it's completely not necessary. This is a bug. No, it's not a bug. It's definitely an intended behavior. PHP does it's best to do the 'right thing' in the most common cases. Because of the way it works, effectively, comparing strings that 'look like numbers' as if they were numbers makes life much, much easier. If you want to enforce a string comparison, use strcmp(). We should document this behavior then - it could lead to problems that are very hard to track down! --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
Yep, we should. It came up many times over the years, this behavior haven't changed since early PHP 3.0.0... Zeev At 19:47 9/2/2001, Zak Greant wrote: Zeev Suraski wrote: At 17:59 9/2/2001, [EMAIL PROTECTED] wrote: ID: 9186 User Update by: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Description: string compare with "==" does not work correctly I think there is no reason to convert any type if both operands of the comparision are of the same type. It costs time and it's completely not necessary. This is a bug. No, it's not a bug. It's definitely an intended behavior. PHP does it's best to do the 'right thing' in the most common cases. Because of the way it works, effectively, comparing strings that 'look like numbers' as if they were numbers makes life much, much easier. If you want to enforce a string comparison, use strcmp(). We should document this behavior then - it could lead to problems that are very hard to track down! --zak -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
How is this? I modified what Zeev said a wee bit: == is a 'loose' comparison operator [1]. In most cases, this is more convenient - the operator does the right thing without needing any coaxing. In some cases, things will happen that are confusing - particularly when comparing values that have leading zeros (0) or when comparing very long numbers that are inside a string. The basic rule to follow is this: Character-by-character comparison is performed only if both arguments are strings and at least one of the strings does not look like a number [2]. Another way to state this rule is: - If at least one of the arguments is not a string, a numeric comparison is made. - If both arguments are strings, but both of them look like numbers, a numeric comparison is made. - If both arguments are strings (and at least one of them doesn't look like a number), a string comparison is made. [1] If you need to perform an exact comparison between two values, take a look at the 'strict' comparison operator (===) and the strcmp() function. [2] See the manual section on types and strings to learn what rules PHP follows for recognising numbers within strings. (Thanks to Zeev for clarifying this issue.) --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly
OK, I was way off base in my reasoning... :-) Thanks for the clarification Zeev and Zak. Alan. How is this? I modified what Zeev said a wee bit: == is a 'loose' comparison operator [1]. In most cases, this is more convenient - the operator does the right thing without needing any coaxing. In some cases, things will happen that are confusing - particularly when comparing values that have leading zeros (0) or when comparing very long numbers that are inside a string. The basic rule to follow is this: Character-by-character comparison is performed only if both arguments are strings and at least one of the strings does not look like a number [2]. Another way to state this rule is: - If at least one of the arguments is not a string, a numeric comparison is made. - If both arguments are strings, but both of them look like numbers, a numeric comparison is made. - If both arguments are strings (and at least one of them doesn't look like a number), a string comparison is made. [1] If you need to perform an exact comparison between two values, take a look at the 'strict' comparison operator (===) and the strcmp() function. [2] See the manual section on types and strings to learn what rules PHP follows for recognising numbers within strings. (Thanks to Zeev for clarifying this issue.) --zak -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
