Generally speaking I would not depend on the particular value for true/false from comparison operators. Usually, Zero is considered to be False, and non-Zero to be True.
In LSL, I'm not aware of the language specifying the precise result of inequality, and in fact were I implementing it, I'd seriously consider simply doing an XOR operation.
Since TRUE and FALSE are simply constant integers, why not:
if ((a == TRUE) || (a == FALSE)) ...
for your test? Yes, you end up executing a couple more bytecodes, but you are certain that you're actually testing what you want to test, the code is more readable and hence more easily maintained, in the long run, it's better code (IMHO).
Cheers,
Corvan.
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters
in the case of '(A != B)' the result will be '0' or '1' unless 'A' and
'B' are lists, in which case the result will be '(llGetListLength( A )
- llGetListLength( B ))'. if you are truly worried about the return
from the operation, you can prefix it with '!!' to force reduction to
'0' or '1'