OSX behaves differently in vector completion
Closed this issue · 3 comments
Makopo commented
Testing code (excerpted from mono/casts.lsl) :
default { state_entry() {
list failed;
if (( // $[E20012]
(string)((vector)"<1,1,infi") != "<0.00000, 0.00000, 0.00000>"
)) failed += 39;
}}
On linux:
TOTAL:: Errors: 0 Warnings: 0
script [none] (cv=(null)) (0,0)
node [none] (cv=(null)) (1,1)
state [none] (cv=(null)) (1,1)
node [none] (cv=(null)) (1,1)
event handler [none] (cv=(null)) (1,11)
identifier "state_entry" [none] (cv=(null)) (1,11)
node [none] (cv=(null)) (1,11)
compound statement [none] (cv=(null)) (1,25)
declaration [(null)] (cv=(null)) (4,1)
identifier "failed" [list] (cv=(null)) (4,6)
node [none] (cv=(null)) (4,1)
if [none] (cv=(null)) (6,1)
expression: =0 [integer] (cv=integer constant: 0) (6,5)
expression: =289 [integer] (cv=integer constant: 0) (7,6)
typecast expression [string] (cv=string constant: `<0.00000, 0.00000, 0.00000>') (7,6)
typecast expression [vector] (cv=vector constant: <0, 0, 0>) (7,15)
expression: =0 [string] (cv=string constant: `<1,1,infi') (7,23)
string constant: `<1,1,infi' [string] (cv=string constant: `<1,1,infi') (7,23)
expression: =0 [string] (cv=string constant: `<0.00000, 0.00000, 0.00000>') (7,49)
string constant: `<0.00000, 0.00000, 0.00000>' [string] (cv=string constant: `<0.00000, 0.00000, 0.00000>') (7,49)
statement [none] (cv=(null)) (8,4)
expression: '=' [list] (cv=(null)) (8,4)
lvalue expression [list] (cv=(null)) (8,4)
identifier "failed" [list] (cv=(null)) (8,4)
expression: '+' [list] (cv=(null)) (8,4)
lvalue expression [list] (cv=(null)) (8,4)
identifier "failed" [list] (cv=(null)) (8,4)
expression: =0 [integer] (cv=integer constant: 39) (8,14)
integer constant: 39 [integer] (cv=integer constant: 39) (8,14)
node [none] (cv=(null)) (6,1)
On osx:
WARN:: ( 6, 5): Condition is always true.
TOTAL:: Errors: 0 Warnings: 1
script [none] (cv=(null)) (0,0)
node [none] (cv=(null)) (1,1)
state [none] (cv=(null)) (1,1)
node [none] (cv=(null)) (1,1)
event handler [none] (cv=(null)) (1,11)
identifier "state_entry" [none] (cv=(null)) (1,11)
node [none] (cv=(null)) (1,11)
compound statement [none] (cv=(null)) (1,25)
declaration [(null)] (cv=(null)) (4,1)
identifier "failed" [list] (cv=(null)) (4,6)
node [none] (cv=(null)) (4,1)
if [none] (cv=(null)) (6,1)
expression: =0 [integer] (cv=integer constant: 1) (6,5)
expression: =289 [integer] (cv=integer constant: 1) (7,6)
typecast expression [string] (cv=string constant: `<1.00000, 1.00000, Infinity>') (7,6)
typecast expression [vector] (cv=vector constant: <1, 1, inf>) (7,15)
expression: =0 [string] (cv=string constant: `<1,1,infi') (7,23)
string constant: `<1,1,infi' [string] (cv=string constant: `<1,1,infi') (7,23)
expression: =0 [string] (cv=string constant: `<0.00000, 0.00000, 0.00000>') (7,49)
string constant: `<0.00000, 0.00000, 0.00000>' [string] (cv=string constant: `<0.00000, 0.00000, 0.00000>') (7,49)
statement [none] (cv=(null)) (8,4)
expression: '=' [list] (cv=(null)) (8,4)
lvalue expression [list] (cv=(null)) (8,4)
identifier "failed" [list] (cv=(null)) (8,4)
expression: '+' [list] (cv=(null)) (8,4)
lvalue expression [list] (cv=(null)) (8,4)
identifier "failed" [list] (cv=(null)) (8,4)
expression: =0 [integer] (cv=integer constant: 39) (8,14)
integer constant: 39 [integer] (cv=integer constant: 39) (8,14)
node [none] (cv=(null)) (6,1)
Tested in inworld, <0.00000, 0.00000, 0.00000> seems to be true.
Sei-Lisa commented
Thanks for the report. The problem is that in OSX we get a valid vector <1, 1, inf> from the expression (vector)"<1,1,infi":
typecast expression [vector] (cv=vector constant: <1, 1, inf>) (7,15)
expression: =0 [string] (cv=string constant: `<1,1,infi') (7,23)
when the expected result is to invalidate the vector:
typecast expression [vector] (cv=vector constant: <0, 0, 0>) (7,15)
expression: =0 [string] (cv=string constant: `<1,1,infi') (7,23)
So, the C library used by Apple is considering "infi" as a valid value for infinity, while glibc is rejecting it. It's not surprising, as that behaviour is pretty surprising in glibc.
I'm working on a patch, not sure how long it will take.
Sei-Lisa commented
Not sure why this wasn't automatically closed, but it's fixed by #97. [Edit: Ah, I typed the wrong bug number in the commit message 😭 ]