What do these constants mean exactly?

[Love Zhaoying]

I would like to know the special significance of "0x7FFFFFF0" and "0x8000000F" in the context of the examples below.  My guess was that "0x80000000" means "-1".

I found them used in other examples also. None of the examples explained how these constants were being used. I understand how negative indexes work with llSubStringIndex(), just not these constants.

My only clues are: "0x8000000F" is integer value positive "2147483663" ..and "0x80000000" is positive integer value 2147483632.  These would both seem to be negative integers, I am guessing "-15" and "-1".

From the llSubStringIndex() page:

integer startswith(string haystack, string needle) // http://wiki.secondlife.com/wiki/llSubStringIndex
{
    return llDeleteSubString(haystack, llStringLength(needle), 0x7FFFFFF0) == needle;
}

integer endswith(string haystack, string needle) // http://wiki.secondlife.com/wiki/llSubStringIndex
{
    return llDeleteSubString(haystack, 0x8000000F, ~llStringLength(needle)) == needle;
}

[Rachel1206]

It seems to be max value of an 32 bit integer and looks like some old stuff. Take a look at llDeleteSubString() - where -1 specify open inquiry of the length on the string examined and 0 (zero) the start.

 

 

Edited June 2, 2017 by Rachel1206

[Rolig Loon]

The integer data type in LSL is a signed 32 bit value between −2,147,483,648 and +2,147,483,647 (that is 0x80000000 to 0x7FFFFFFF in hex).  If you exceed the range on either end, values wrap around, so, for example, 0x8000000F becomes a positive value.

[Love Zhaoying]

Hmm...so it's a hack to specify a number that acts "kind of like -1" for llSubStringIndex() but in a positive fashion. Does that make sense?

Otherwise, why use a constant?

12 minutes ago, Rolig Loon said:

The integer data type in LSL is a signed 32 bit value between −2,147,483,648 and +2,147,483,647 (that is 0x80000000 to 0x7FFFFFFF in hex).  If you exceed the range on either end, values wrap around, so, for example, 0x8000000F becomes a positive value.

So this is a way to hack "> max positive integer" as a flag?

 

[Love Zhaoying]

1 hour ago, Rachel1206 said:

It seems to be max value of an 32 bit integer and looks like some old stuff. Take a look at llDeleteSubString() - where -1 specify open inquiry of the length on the string examined and 0 (zero) the start.

I only found references to "-1" meaning "end of the string", yes that implies "length of the string".  But, I did not see anything that explains the use of these constants.

[Rolig Loon]

2 minutes ago, Love Zhaoying said:

So this is a way to hack "> max positive integer" as a flag?

Yes.

[Rachel1206]

2 hours ago, Love Zhaoying said:

I only found references to "-1" meaning "end of the string", yes that implies "length of the string".  But, I did not see anything that explains the use of these constants.

What I meant use -1 and 0 instead of the hex values ( defining max/min ) shown in the old example. Do not rely on fixed max/min definition of variable values. The SL server will handle it for you and it ensures, it is future safe, if the definitions should change.

 

[Nova Convair]

integer a=-1 uses more memory than a=0x80000000 - well I didn't test it myself.

I assume someone wants to save a byte or 2. And someone has made a pre processor/optimizer for LSL that will perform this kind of replacements too. (check the other forum)

For manual usage it's not worth the efforts, by my opinion.

[Love Zhaoying]

On 6/4/2017 at 8:07 AM, Nova Convair said:

 

integer a=-1 uses more memory than a=0x80000000 - well I didn't test it myself.

I assume someone wants to save a byte or 2. And someone has made a pre processor/optimizer for LSL that will perform this kind of replacements too. (check the other forum)

For manual usage it's not worth the efforts, by my opinion.

 

Yes, I saw the article that said it took less to compile "0x8..." than -1.  However, these were different negative constants, not "-1". That was the real mystery for me, not "why" but "what those constants meant" since they were not -1.

[Qie Niangao]

Looking into the wiki revision history for this article, this all seems too obscure for my limited patience. Apparently on March 11, 2013, Strife introduced those unusual constant values with the comment "I recall LSO ll(Get/Delete)SubString having issues with Max and Min ints" in a change discussed on the talk page :

Quote

sigh* Fix one bug, introduce another. The implementation on the page was originally based on llGetSubString, the problem with llGetSubString, it's incapable of returning an empty string (unless you push both the start and end past the end of the array). As such it fail to work on needles that are empty strings. I've put in some better constants that should keep it from deleting a character when they match. -- Strife (talk|contribs) 11:59, 11 March 2013 (PDT)

all as part of fixes by multiple authors for a bug when needle == haystack.

As I've already admitted, I'm too lazy to really track this down, but it doesn't seem to be about efficiency.

[Love Zhaoying]

Aside from the inefficiency of interpreting negative numbers, a better way of coding "EndsWith()" would seem to be:

If (llGetSubString(Haystack, -1 * llStringLength(Needle), -1)==Needle)

    then the checked string (haystack) ends with the desired string (needle).

This would take advantage of negative indexing to find the last portion of the Haystack of the same length as Needle.

This is how I was going to do it. Agree? Disagree?