• 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: SVC-113
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Haravikk Mistral
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
2. Second Life Service - SVC

List equality doesn't actually test equality!

Created: 13/Apr/07 02:07 PM   Updated: 30/Sep/09 01:32 PM
Return to search
Component/s: Scripts
Affects Version/s: 1.13.4, 1.21.0 Server, 1.22.1 Server, 1.22.2 Server, 1.22.3 Server, 1.22.4 Server, 1.23.4 Server, 1.24 Server, 1.25 Server, 1.26 Server, 1.27 Server, 1.30 Server
Fix Version/s: None

Issue Links:
Duplicate
 
Relates


 Description  « Hide
Consider the following two lists:
list a = [1,2,3];
list b = [2];
They aren't equal right? So does a == b evaluate to FALSE? Yeah it does! Perfect.

Consider these two lists:
list a = [1,2,3];
list b = [1,2,3];
They're equal right? So does a == b evaluate to TRUE? Yes! Perfect.

Now the last pair of lists:
list a = [1,2,3];
list b = [4,5,6];
These two lists are completely different...right? So does a == b evaluate to FALSE? NO! Per....wait a minute!

list == list does NOT compare the two lists, it seems to only compare the LENGTHS of the two lists. So if two DIFFERENT lists are both of length 3, they will be 'equal' in LSL. This is non-sensical behaviour!

To fix this we need a fairly lengthy LSL function which I believe does exactly what list == list should do now. Therefore I propose that == simply be altered to implement this new behaviour, it has little performance impact unless someone compares two big lists, and if implemented as an LSL operator would have no real memory overhead (since it wouldn't need to copy the lists). This may break some content, however anything that it does break will be broken only because it exploits incorrect behaviour, as we all know what == /should/ mean. If the broken content is too much to handle, then please implement a new operator just for lists, that is the triple equals ===. This would compare the lists EXACTLY.

The LSL function which currently does this CORRECT comparison (returns TRUE if equal, false if not):
integer listEqualsList(list a, list b) {
integer x = llGetListLength(b);
if (llGetListLength(a) == x) { // Lengths are equal, compare contents
if (x > 0) { // Only if it has contents though!
integer t;
@listEqualsListLoop;
t = llGetListEntryType(a, --x);
if (t == llGetListEntryType(b, x)) {
if (t == TYPE_INTEGER) { if (llList2Integer(a, x) != llList2Integer(b, x)) return FALSE; } else if (t == TYPE_STRING) { if (llList2String(a, x) != llList2String(b, x)) return FALSE; } else if (t == TYPE_FLOAT) { if (llList2Float(a, x) != llList2Float(b, x)) return FALSE; } else if (t == TYPE_KEY) { if (llList2Key(a, x) != llList2Key(b, x)) return FALSE; } else if (t == TYPE_VECTOR) { if (llList2Vector(a, x) != llList2Vector(b, x)) return FALSE; } else if (t == TYPE_ROTATION) { if (llList2Rot(a, x) != llList2Rot(b, x)) return FALSE; }
} else return FALSE;
if (x > 0) jump listEqualsListLoop;
}
return TRUE;
} return FALSE;
}



 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
Haravikk Mistral added a comment - 13/Apr/07 04:12 PM
Would help if I posted the correct LSL function first time round

Lex Neva added a comment - 14/Apr/07 09:02 AM
Hah, nifty. This sounds like lists in SL behave how arrays in PERL do: if you refer to the list in a "numerical context", you'll get the list's length. I agree this is less than useful for comparing lists. I'd like to see either a fix of the == operator or a llListCompare function. Not only is the function as you show it rather big on code, it's also horribly inefficient: running through two lists like this will be O(n^2).

Strife Onizuka added a comment - 15/Apr/07 01:17 AM
How List compares work:
!= (not equivalent) return the difference in lengths (a != b is equivalent to llGetListLength(a) - llGetListLength(b)).
== (equivalent) return true if the lengths are the same.

Fixing this would break existing content in LSL and cause confusion by having != and == working differently. The length comparison quirk is documented on the various wikis.

I generally oppose any changes that break existing content and I feel the same about changes that introduce confusion. I cannot in good conscious support this feature request.


Lex Neva added a comment - 15/Apr/07 09:11 AM
Strife, if you counted on != on a list returning the difference in lengths, you deserve to have your script broken.

meade paravane added a comment - 16/Apr/07 11:36 AM
I kinda agree with Strifes comment. Maybe a new LSL function that did the 'correct' thing would be better than changing the way an existing function works.

On the other hand, if I could vote for an individual comment, I'd cast a ballot for Lex's last one.


Gellan Glenelg added a comment - 16/Apr/07 05:32 PM
It is well documented that == compares the length of two lists.
It is reasonable to assume that people have written code which relies on this.
Fixing this would break existsing scripts.

There is a much simpler function to compare list equality. see http://rpgstats.com/wiki/index.php?title=Annoyances


Haravikk Mistral added a comment - 03/May/07 05:23 AM
Umm...I counted for this in the bug report. I suggested using === to EXACTLY compare lists. This way people who (IMO wrongly) used == and != to compare lists will not have their content broken, but if you use triple-equals you will get an exact list comparison.
Triple-equals is used in many languages to allow you to compare other return values exactly, such as a comparison between a result of zero and a result of false in many typed languages, so it would make sense to use it for lists as well.

Gigs Taggart added a comment - 11/May/07 12:47 AM
Changing to feature request. The current behavior is by design, and therefore not a bug.

Tyken Hightower added a comment - 09/Sep/07 01:52 AM
integer compare_lists(list a, list b) {
if (llGetListLength(a) == llGetListLength(b)) { if (!llListFindList(a, b)) return TRUE; }
return FALSE;
}

Tyken Hightower added a comment - 09/Sep/07 01:54 AM
And that was supposed to be list_equals_list. Weee.

Tyken Hightower added a comment - 09/Sep/07 01:56 AM
And hey, the one on the wiki is better, even.

anthony reisman added a comment - 11/Sep/07 12:58 PM
maybe it would be better to just have a function like llListCompare(list one, list two)?

I agree that making a change that might break functionality is probably not a good idea.

Also couldn't it be argued that == should only return true if both names point to the same list (not just lists with the same content)?


Strife Onizuka added a comment - 20/Sep/07 06:58 PM
Changing the behavior or == and != would break existing content. A new list function like llListCompare is the best solution to this problem.

Nicoladie Gymnast added a comment - 12/Sep/08 07:10 AM
Hmmm... if comparison of 2 lists is comparing the length instead of the list content itself, then the comparison is of the type integer.

So would this make sense?

list a = [1];
list b = [2];

if (a == b) //so this is type integer comparison because we are comparing the length of the list, right?
then ....

if (a == 1) //Is this type integer comparison or type list comparison? Are we comparing length of the list or the content of the list? Which type takes precedence? list or integer? You would say list takes precedence because the list a comes first, right?

How about this?
if (1 == a) //This time, integer comes first. So will it force it to evaluate the length of the list? Instead of flagging an type-checking error of incompatible type comparison?

If you write codes like this, then the code and content needs to be broken. It violates every single programming syntax and type checking. It is absurd to write code like this.

Time to fix this when mono comes online.

We have to recompile all your code in mono anyways, so why not fix it now once and for all, instead of perpetuating horrible bug that violates any programming language.


Strife Onizuka added a comment - 25/Sep/09 10:51 AM
@Nicoladie: As I recall both Java and C, when using character arrays, if you compare them against each other directly, it just does a pointer comparison and doesn't even look at the values. While LSL's behavior is by all means strange, it is not the strangest and at least it's remotely useful.