[PHP-DEV] PHP 4.0 Bug #9186 Updated: string compare with == does not work correctly

2001-02-15 Thread zeev

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

2001-02-15 Thread tom . anheyer

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

2001-02-15 Thread hholzgra

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

2001-02-15 Thread tom . anheyer

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

2001-02-14 Thread sniper

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

2001-02-09 Thread zak

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

2001-02-09 Thread tom . anheyer

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

2001-02-09 Thread zak

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

2001-02-09 Thread Zak Greant

As much as I hate to be wrong, I have to say that you are correct.

--zak

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, February 09, 2001 8:59 AM
Subject: [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 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

2001-02-09 Thread Alan van den Bosch



 As much as I hate to be wrong, I have to say that you are correct.

Maybe I'm missing something very subtle here, but I think your first
apraisal was correct Zak.

  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.

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)


regards

alan.


-- 
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

2001-02-09 Thread Zak Greant

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

2001-02-09 Thread Hartmut Holzgraefe

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

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


=== , on the other hand, works like this:

if left-hand-type != right-hand-type
  result is false
else
  compare unconverted left-hand-argument to unconverted
right-hand-argument

-- 
Hartmut Holzgraefe  [EMAIL PROTECTED]  http://www.six.de  +49-711-99091-77 

Besuchen Sie uns auf der CeBIT 2001 - in Halle 6 Stand F62/4

-- 
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

2001-02-09 Thread Zeev Suraski

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

2001-02-09 Thread Zeev Suraski

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

2001-02-09 Thread Zak Greant

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

2001-02-09 Thread Zeev Suraski

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

2001-02-09 Thread Zak Greant

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

2001-02-09 Thread Alan van den Bosch


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]