Type casting error in LSL?

I think there is an error when type casting the strings "09" and "08" to type integers (and then back to string in order to print it). The problem doesn't exist for "07", "06", etc., all the way down to "00"... its just an issue with "09" and "08". You can see the script below followed by the (apparently) erroneous output:

default
{
    state_entry()
    {
        // Do nothing.
    }

    touch_start(integer total_number)
    {
        string sNine = "09";
        integer iNine = (integer)sNine;
        llSay(0, sNine + " cast to integer is: " + (string)iNine);
        
        sNine = "08";
        iNine = (integer)sNine;
        llSay(0, sNine + " cast to integer is: " + (string)iNine);
        
        sNine = "07";
        iNine = (integer)sNine;        
        llSay(0, sNine + " cast to integer is: " + (string)iNine);
        
        sNine = "06";
        iNine = (integer)sNine;
        llSay(0, sNine + " cast to integer is: " + (string)iNine);
        
        sNine = "05";
        iNine = (integer)sNine;        
        llSay(0, sNine + " cast to integer is: " + (string)iNine);
        
        sNine = "04";
        iNine = (integer)sNine;        
        llSay(0, sNine + " cast to integer is: " + (string)iNine);
        
        sNine = "03";
        iNine = (integer)sNine;        
        llSay(0, sNine + " cast to integer is: " + (string)iNine);
        
        sNine = "02";
        iNine = (integer)sNine;        
        llSay(0, sNine + " cast to integer is: " + (string)iNine);
        
        sNine = "01";
        iNine = (integer)sNine;        
        llSay(0, sNine + " cast to integer is: " + (string)iNine);
        
        sNine = "00";
        iNine = (integer)sNine;        
        llSay(0, sNine + " cast to integer is: " + (string)iNine);
        
    }
}

The output is:

Object: 09 cast to integer is: 0
Object: 08 cast to integer is: 0
Object: 07 cast to integer is: 7
Object: 06 cast to integer is: 6
Object: 05 cast to integer is: 5
Object: 04 cast to integer is: 4
Object: 03 cast to integer is: 3
Object: 02 cast to integer is: 2
Object: 01 cast to integer is: 1
Object: 00 cast to integer is: 0

Am I missing something with the casting, or is this a legitimate problem?

Tigs

Good catch. Inconsistent behaviour like this is evil in the worst way.

It should be fixed to either report 9/8 (much preferable..) or "0" for everything.

That's the weirdest bug I've ever seen. What on earth could be causing it?

This is not a bug, but it is a compatibility issue. It is caused by the new support for octal (and hexadecimal) input added in 1.5.

When you prefix a number with a zero it will no longer be interpreted as decimal (like in 1.4), but as octal. This means only the digits 0..7 are valid, everything else is invalid and thus returns 0, causing the behaviour you noticed.. You'll also notice that "010" will be converted to 8 decimal instead of 10. To adapt your script to this change, you'll have to strip any leading zeroes (unless it is octal you want).

UGH! That means that you would have to do something like:

if ( integer number < 10 )
{
llSay(0, "0" + (string)number)
}

Because you can no longer put the prefix of a zero on that number...

WOOF!

Good catch, I'll take out octal. It seems to be causing more trouble than its worth at this point.

Ah, I didn't even realize there was octal support now. I'll still adjust my scripts to strip the leading "0", but its good to at least know what the cause of the problem was.

Tigsen

i think binary would have been better then octal. (in all the years i've been coding i've never used octal)

Would it be possible to identify binary/octal/hexadecimal directly?

b00, o00, h00 or something similar?

Hex already does this, to an extent, if you consider "0x" to be the identifyer prefix.

Id also like direct binary imput.

I really dont think LL should overload integer casting with Yet Another Useless Functionality (TM). Casting should perform the string -> base10 integer conversion, and that's all. If a string -> hexidecimal conversion is needed, it should be added in function form. Something like llHexString2Integer() would be suitable. This way, everyone's needs can be satasfied, even the people who want string -> octal conversion (with the addition of an llOctalString2Integer() function).

Casting a string in the form "0x1234" to an integer should yield 0, since "0x1234" is not a valid base-10 integer.

==Chris

Yeah, I guess that makes sense. Fair enough.

The advantage of having it in the typecast is that old code can handle the new format without having to be changed, and no identification is needed in the code to handle the different types.

Type casting is a serious issue that every script faces at some point in its career. Once a script has seen some fame in a particular role it get "locked" into it. Scripters and users of scripts should take the time to see a scripts TRUE talent and give it the opportunity to perform in off beat roles. We could be missing some amazing performances from famous scripts simply because no one can see past their most notable role.

*reads thread*

Oh.. uhh, yeah... octal... numbers are cool..

I'm sure Strife knows this, but for anyone else, it is super easy to convert hex to binary and binary to hex (because 16 is a power of 2, but that's not important).

Take this table:

0000    0
0001    1
0010    2
0011    3
0100    4
0101    5
0110    6
0111    7
1000    8
1001    9
1010    a
1011    b
1100    c
1101    d
1110    e
1111    f

to convert hex to binary, just replace each hex digit with the group of 4 binary digits. To convert binary to hex, divide the number in to groups of 4, adding 0s at the left end if necessary, then convert each group in to is corresponding hex digit.

How about a 0o (zero, letter o) prefix instead? It would be consistent with hex notation.

Honestly I have never used octals for any reason, except when I had to write an n-base converter for a couple programming classes.

I was actually bit by this same bug in C++ the other day. I had a bunch of hard-defined enums with four digit values (1001,2006,5034,etc) then added a few small numbers for special cases and padded them with zeros to make the code prettier (0010, 0020,0030,etc). It's been like that for ages. But then I was printing out the values to find a bug, and saw "8, 16, 24" and no idea where those numbers were coming from. Had to look at the old enum define code to figure it out. They were being converted to octal because of the leading zeros.

Octal isn't very useful most of the time. It's greatest claim to fame is that it is half of hex. But still...