• All submissions to this site are governed by Second Life Project Contribution Agreement. By submitting patches and other information using this site, you acknowledge that you have read, understood, and agreed to those terms.
Issue Details (XML | Word | Printable)

Key: VWR-2497
Type: Bug Bug
Status: Closed Closed
Resolution: Won't Finish
Priority: Normal Normal
Assignee: Unassigned
Reporter: Ochi Wolfe
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
1. Second Life Viewer - VWR

String "!=" comparison evaluates incorrectly

Created: 17/Sep/07 06:08 AM   Updated: 11/Jul/08 12:36 PM
Return to search
Component/s: Scripting
Affects Version/s: 1.18.3 Release Candidate, 1.18.0, 1.18.1.2, 1.18.2.0
Fix Version/s: 1.18.3 Release Candidate, 1.18.0, 1.18.1.2, 1.18.2.0

Environment:
Xubuntu 7.04
Intel Core 2 Duo E6700, 2 x 2.6 GHz
4 GB DDR2 PC8500
ASUS NVIDIA GeForce 8800 GTS, 640 MB VRAM


 Description  « Hide
Reproduction:
  • Try this code:
    <code>
    llOwnerSay( (string)( "b" != "a" ) );
    llOwnerSay( (string)( "a" != "b" ) );
    </code>

Observed results:
The first comparison returns "1" which is correct.
The second comparison returns "-1" which is incorrect.

This might be a potential security risk, don't compare keys this way. Meanwhile, I use !( "a" == "b" ) instead.



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Lex Neva added a comment - 17/Sep/07 08:59 AM
Why is this a problem? -1 is still equivalent to a true boolean value.

Ochi Wolfe added a comment - 17/Sep/07 10:19 AM
It is a problem because TRUE == 1 != -1. These two comparisons should both evaluate to true

( "a" != "b" ) == TRUE
( "b" != "a" ) == TRUE

but they don't.


Lex Neva added a comment - 18/Sep/07 08:56 AM
I'm pretty sure this same thing happens in a lot of languages, such as C/C++. Conditional statements like if(foo) really test whether foo is not equal to zero. Any nonzero value is equivalent to a true boolean value. TRUE is just a convenient constant that happens to equate to a true boolean value. I don't think the behavior you're seeing needs to be changed. Just don't do anything silly like add up values returned by !=.

Ochi Wolfe added a comment - 18/Sep/07 09:39 AM
I don't see any reason why the expression should return different values for the same logical comparison - despite the fact that in C++ the following char comparisons do return 1 in both cases:

Code:
#include <iostream>
using namespace std;
int main()
{
cout << (int)('a' != 'b') << endl;
cout << (int)('b' != 'a') << endl;
return 0;
}

Result:
1
1

Well, we'll let the Lindens decide I suppose


Strife Onizuka added a comment - 18/Sep/07 05:41 PM
In your c++ example you are doing single character comparisons which is very different beast. A single character comparison in C++ is an integer based operation.

A != operator used on character arrays in C++ would just compare the pointers and would always return false (assuming the compiler hadn't optimized the constant strings). To compare character arrays in C++ you use strcmp, which is what the LSL VM does (it was written in C++). strcmp is part of the ANSI C standard.

"Fixing" this would break existing code.



Ochi Wolfe added a comment - 18/Sep/07 05:49 PM
Okay, I am convinced. ^^ I'll close this issue now.

Ochi Wolfe added a comment - 18/Sep/07 05:52 PM
No need to change anything.

Shibiku Yoshikawa added a comment - 11/Jul/08 12:36 PM
I would like to propose a reopening of this issue and that the chance to fix this as mono is introduced be taken.

One should treat the EQUALITY and INEQUALITY operator as the way the operations of EQUALITY are defined, with the only valid outcomes being TRUE (1) and FALSE (0).

Motivation:
1) The operators != and == are operations of equality and either two objects are equal or they are not equal there are only two logical outcomes, TRUE and FALSE. Mathematics and logic agree with me here.

2) The operators != and == are per definition NOT string comparsion (C::strcmp) operators in any other language.

3) The behavior is inconsistent with the other types' operators, most specifically this is utter nonsense:
The comparsion ( "1" != "2" ) == ( 1 != 2 ) is FALSE. While ( (integer)("1") != (integer)("2")) == (1 != 2) is TRUE.

4) In the lack of a C++ expression like this:
value = (expression ? value if true : value if false);

One might want to replace
if( a == b ){
value = 1;
}
else{
value = -1;
}

with:
value = 1 - 2*( a != b);

Which won't work reliably with the current definition of the string operator.

Correction to above "semi C+" example. The correct way to do it (in C+) is:

#include <iostream>
#include <string>
using namespace std;
int main(int argc, char* argv[] ){
string one = "1";
string two = "2";
cout<< (int)(one != two) <<endl;
}

Which will indeed print 1as one would expect.

Proposed solution:
1) Change behavior of == and != of strings to be an equality comparsion, returning only TRUE(1) or FALSE(0)
2) Introduce a new function named llStrCmp(string a, string b) that functions like strcmp from C.