Is there an explanation for this strange behavior?

[Triple Peccable]

Please explain this script's output (when it is mono compiled):

 

default
{
    touch_start(integer total_number)
    {
        llOwnerSay((string)((float)"nan"));
        llOwnerSay((string)((float)"anything other than nan"));
    }
}

 Here is the output:

[14:05]  Object: NaN
[14:05]  Object: 0.000000

If I don't compile it in mono, I get a script error instead of the output:

[14:07]  Object: Object [script:New Script] Script run-time error
[14:07]  Object: Math Error

Unless "nan" has some numerical meaning that I am unaware of, this looks like a bug to me. Any comments?

 

[Scripter Coba]

I don't know if it explains the behaviour, but NaN does indeed have a special behaviour

 

http://lslwiki.net/lslwiki/wakka.php?wakka=NaN

 

 

[Cerise1488303085]

Hi, yes, normally Mono handles unusual results like divide by zero by returning NaN instead of a fatal error. The divide by zero case got a special modification in response to SVC-4805, but NaN still has its special meaning.

[Triple Peccable]

Well, I didn't think that typecasting a string to a float is anything unusual. If the string does not contain a numeric value, then it should always return zero.

 

[Cerise1488303085]

That is the catch, in Mono NaN is a numeric value. It is part of the IEEE-754 standard.

[Triple Peccable]

Ok, but I still have an issue with this behavior. The string does not have to equal "nan", it only has to start with nan. If the string was Nantucket, I would get NaN instead of 0.00000, then when that result gets used in a calculation a fatal script error occurs (Math Error).

This causes obscure bugs. For example, I had a visitor who's first name was nana. My "working perfectly" script suddenly crashed with a Math Error. If this is not a bug, then i will have to test strings to make sure they do not start with "nan" before I typecast them. I should not have to do that.

 

[Void Singer]

I agree that the behavior is stupid... it shouldn't truncate a string, in fact, since nan is no longer processable by MONO (a dumb move if you ask me) it shouldn't be processed at all....

it's also not the only value to do it.... Infinity (inf/iformation) exibits the exact same behavior.

 

but there you have it, that is the "reason".... now get thee over to jira, and complain.... bring up back the link so we can all go and support you.

personally I'd like to see them restore MONO's signalling behavior, and even expand on the NaN handling to give full signalling values..... then you could stuff keys inside of rotations. but at the very least this truncation nonsense needs to stop, and if they aren't going to fix extended values, then they shouldn't read them at all.

[Triple Peccable]

Yep, you're right. "inf" returns "Infinity" as the typecast result.

Now that I know this is a known issue, I will code around it. Then I might get around to a JIRA (although I'll be surprised if there is not one already created).

Thanks.

 

[Void Singer]

well.... known now =/

I didn't realize that it would truncate a string to pull the value out like that before this post (I did know you could typecast the three letter versions, because I TRIED to get it to report extended NaN signalling to make a key crusher)

[Triple Peccable]

Well, if you would like to be the one to create the JIRA on it, feel free.

Left the way it is, it will continue to cause hard-to-reproduce obscure script crash problems.

 

[Void Singer]

I tried to see if I could come up with a use for the current behavior....

there's one, purposely crashing a script compiled to LSO, and there could be more IF they tweaked MONO...

 

but since it's still broken on some level no matter what... SVC-6847

which has the workaround:

(float)llList2String( llParseStringKeepNulls( llToLower( llStringTrim( vStrDta, STRING_TRIM ) ), ["inf", "nan"], [] ), 0 )

 

ETA:
wiki has been updated to include a link to the issue and the workaround

[Triple Peccable]

That's great, but are we sure that nan and inf are the only two problem strings?

 

[Void Singer]

yes, those and their variations....  for instance, any number of spaces in front, and/or a leading negation, and any trailing characters.

those are the only one specified in the IEEE-754(1985) standard and are used to handle all 5 exception cases in the 2008 version of the standard.