Talk:LSL Language Test

<lsl> // post increment.

   i = 1;
   ensureIntegerEqual("i = 1; (i == 2) && (i++ == 1)", (i == 2) && (i++ == 1), TRUE);
       
   // pre increment.
   i = 1;
   ensureIntegerEqual("i = 1; (i == 2) && (++i == 2)", (i == 2) && (++i == 2), TRUE);
       
   // post decrement.
   i = 2;
   ensureIntegerEqual("i = 2; (i == 1) && (i-- == 2)", (i == 1) && (i-- == 2), TRUE);
       
   // pre decrement.
   i = 2;
   ensureIntegerEqual("i = 2; (i == 1) && (--i == 1)", (i == 1) && (--i == 1), TRUE);</lsl>

These tests are good for LSO-LSL but do we want to propagate this order of execution to Mono-LSL? -- Strife Onizuka 19:16, 7 December 2007 (PST)

LSO failure

Is this expected under the existing system?

 FAILED: testReturnFloat() (0.000000 expected 1.000000)

It only happens if you try returning an int as a float - returning a float as a float works as expected. I can't test behaviour under mono because there isn't a TG beta grid. - Katharine Berry 11:08, 4 February 2008 (PST)

Yes, look at the test. <lsl> float testReturnFloat() {

  return 1;

} </lsl> Do you think it should be 0.0 or 1.0? We may fix this LSL2 bug once we have fewer Mono bugs to fix. -- Scouse Linden 21:53, 5 February 2008

It is definitely an error in LSO. It should return 1.0, it should NOT return 0.0. What it currently returns is not infact 0.0 but 0x1p-149 (use Float2Hex to show this). What is happening is that an integer is being pushed into a stack position that later gets read back out as a float. This is most definitely a compiler error, integer to float conversion has an implicit typecast but it seems that the compiler forgot to make it explicit. It would be nice to have some LSL function that does two way conversions from floats to integers and back based on how they are stored in memory. -- Strife Onizuka 11:30, 5 February 2008 (PST)