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

[Telemann, Bo]

I accept your reasons for doing so. 
But actually this behaviour makes the "==" comparision to a "maybe".
"Maybe they are equal." Documentation of this working will be helping not 
much. The users of PHP have to understand the working of "==" at the lowest 
level. 

I suggest, that you check your convert to a number. If the result is MAXINT, 
MININT or NaN, it would be better not converting the operands and making a 
string comparision.  
   
In this case you havn't to make an extra documentation on this behaviour and 
this operation will work like users expect.



Am Freitag,  9. Februar 2001 20:31 schrieb 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

-- 
Tom Anheyer
G+J BerlinOnline GmbH Tel. :  +49-(0)30-2327-5210
im Pressehaus am Alexanderplatz   Fax:+49-(0)30-2327-5596
Karl-Liebknecht-Straße 29 E-Mail: [EMAIL PROTECTED]
D-10178 BerlinURL:http://www.BerlinOnline.de

BerlinOnline ist ein Service von Berliner Zeitung, TIP BerlinMagazin,
Berliner Kurier und Berliner Abendblatt.

-- 
PHP Development Mailing List 
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]

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

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

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

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

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

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

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

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

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

[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 
> 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 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]