LSL String Comparison 1.8 and 1.9 differences

This morning i came to a shocking discovery. LSL string comparisons do not just return just TRUE or FALSE (which answered the question why XTM in TLML wasn't working). It wasn't actualy all that shocking, most languages don't support string comparison via "==" operator, and so it goes to figure that LL is using strcmp, strcmp returns 1, 0, -1 depending on the result.

default
{
    state_entry()
    {
        llOwnerSay(llList2CSV(["a" != "b", "b" != "a", "a" != "c", "c" != "a", "1" != "a"]));
    }
}

In 1.8 the result of that script was: -1, 1, -2, 2, -48
Giving me reason to beleive the function is something like...

int not_equal_1_8(char * a, char * b)
{
    int d = 0;
    if(a != b)
        for(int c = 0;a[c] && b[c] && (d = (a[c] - b[c])) == 0;++c);
    return d;
}

In 1.9 the result of that script was: -1, 1, -1, 1, -1
Giving me reason to beleive the function is something like...

int not_equal_1_9(char * a, char * b)
{
    int d = 0;
    if(a != b)
        for(int c = 0;a[c] && b[c] && (d = (a[c] - b[c])) == 0;++c);
    return (d<0)?(-1):(d>0);
}

I would like the 1.8 functionality restored. Even though it is a bit bizzar.

But i'm only leaning slightly towards the 1.8 implementation. I'd be happy with what ever it is as long as it's documented what it's results will be.

I'd even be happy with.

int not_equal_1_9(char * a, char * b)
{
    int d = 0;
    if(a != b)
        for(int c = 0;a[c] && b[c] && (d = (a[c] - b[c])) == 0;++c);
    return (d != 0);
}

The functions above i release into public domain.

Well, not entirely sure I am effected by this (though, after tens of thousands of lines of code I really can not say for sure) .. however I am dismayed that LSL functions are changing, not to mention that there was no warning of this.

If you are going change function behaviour, please add a new function. I know, it creates API bloat, but you can deprecate old functions over time.

The alternative is much worse .. breaking existing code immediately with little time to prepare or warn.

So, I do not only agree with Strife on this but I would like to know -- are there any other functions which may have changed? How did this code get touched?

Concerned,

Iron.

I agree with the documentation request, but I think the result should only be -1, 0, 1 (that is, the 1.9 functionality).

I don't think any other output is reasonable, and dependable upon. Eg: think about Unicode characters, where a character is not 'char' (1 byte) but unicode char (2 or 4 bytes, for example).

Zonax, I have a lot of code written which depends on weird LL implemenations.

If they go start fixing things, it will be very problematic for me and I suspect quite a few other people.

The new implementation is correct - but create a new API function for it.

SL supports Unicode though UTF-8, where characters are either 1,2,3,4,5, or 6 bytes; representing the entire 31-bit unicode character space.

I have not tested the 1.8 code with multi-byte UTF-8 characters but i expect it will be doing what i have outlined above which is to read it byte by byte, not character by character. Reading it character by character would be CPU intensive, as the characters would have to be validated and decoded.

Good catch! However, it's not a bug or change in the lsl operator -- it is a problem with the c library installed on the 64 bit machines. Deep inside the recesses of much of the lsl runtime, we rely on c functions to answer some questions. In this case, we are using a call to strcmp. It turns out that a 32 bit compiled application running on a sim with our current 64 bit image returns a different number than you would expect. The 1.8 simulator where you ran tests was almost certainly on a 64 bit host while every machine on the siva grid is on a 32 bit host. We have been running the 64 bit image on some hosts for at least 6 months now, and this is the first time someone has noticed this inconsistency.

We have updated the 64 bit image to include an architecture specific c runtime library which will resume the previous behavior of returning -1 the next time the host is rebooted. Given the track record our colo has maintained, that might not be too far away.