| Key: |
SVC-1342
|
| Type: |
Bug
|
| Status: |
Resolved
|
| Resolution: |
Fixed
|
| Priority: |
Critical
|
| Assignee: |
Unassigned
|
| Reporter: |
Strife Onizuka
|
| Votes: |
0
|
| Watchers: |
2
|
|
If you were logged in you would be able to see more operations.
|
|
|
|
Issue Links:
|
Relates
|
|
|
|
This issue is related to by:
|
|
SVC-1336
Mono Beta: Control inputs not acting properly
|
|
|
|
|
|
|
|
|
|
|
| Linden Lab Issue ID: |
DEV-9749
|
| Linden Lab Internal Branch: |
mono-based-on-77880
|
The && and || operators (Boolean AND and Boolean OR respectively) have been mapped to the bitwise operators. This can result in code that does not work properly when the operands are not pure booleans. What is the point in having separate operators if they do the same thing.
[code]
AND(integer a, integer b)
{
integer c = a && b;
if(c)
llOwnerSay(llList2CSV(["TRUE",a,b,c]));
else
llOwnerSay(llList2CSV(["FALSE",a,b,c]));
}
OR(integer a, integer b)
{
integer c = a || b;
if(c)
llOwnerSay(llList2CSV(["TRUE",a,b,c]));
else
llOwnerSay(llList2CSV(["FALSE",a,b,c]));
}
default
{
state_entry()
{
llOwnerSay("==========================================================");
AND(-38, 1);
AND(1, 2);
AND(1, 1);
AND(11, 7);
OR(-38, 65);
OR(6, -56);
OR(1, 456);
}
}
[/code]
LSO Output:
[3:13] QA HUD - Final 20060428: TRUE, -38, 1, 1
[3:13] QA HUD - Final 20060428: TRUE, 1, 2, 1
[3:13] QA HUD - Final 20060428: TRUE, 1, 1, 1
[3:13] QA HUD - Final 20060428: TRUE, 11, 7, 1
[3:13] QA HUD - Final 20060428: TRUE, -38, 65, 1
[3:13] QA HUD - Final 20060428: TRUE, 6, -56, 1
[3:13] QA HUD - Final 20060428: TRUE, 1, 456, 1
Mono Output:
[3:12] QA HUD - Final 20060428: FALSE, -38, 1, 0
[3:12] QA HUD - Final 20060428: FALSE, 1, 2, 0
[3:12] QA HUD - Final 20060428: TRUE, 1, 1, 1
[3:12] QA HUD - Final 20060428: TRUE, 11, 7, 3
[3:12] QA HUD - Final 20060428: TRUE, -38, 65, -37
[3:12] QA HUD - Final 20060428: TRUE, 6, -56, -50
[3:12] QA HUD - Final 20060428: TRUE, 1, 456, 457
|
|
Description
|
The && and || operators (Boolean AND and Boolean OR respectively) have been mapped to the bitwise operators. This can result in code that does not work properly when the operands are not pure booleans. What is the point in having separate operators if they do the same thing.
[code]
AND(integer a, integer b)
{
integer c = a && b;
if(c)
llOwnerSay(llList2CSV(["TRUE",a,b,c]));
else
llOwnerSay(llList2CSV(["FALSE",a,b,c]));
}
OR(integer a, integer b)
{
integer c = a || b;
if(c)
llOwnerSay(llList2CSV(["TRUE",a,b,c]));
else
llOwnerSay(llList2CSV(["FALSE",a,b,c]));
}
default
{
state_entry()
{
llOwnerSay("==========================================================");
AND(-38, 1);
AND(1, 2);
AND(1, 1);
AND(11, 7);
OR(-38, 65);
OR(6, -56);
OR(1, 456);
}
}
[/code]
LSO Output:
[3:13] QA HUD - Final 20060428: TRUE, -38, 1, 1
[3:13] QA HUD - Final 20060428: TRUE, 1, 2, 1
[3:13] QA HUD - Final 20060428: TRUE, 1, 1, 1
[3:13] QA HUD - Final 20060428: TRUE, 11, 7, 1
[3:13] QA HUD - Final 20060428: TRUE, -38, 65, 1
[3:13] QA HUD - Final 20060428: TRUE, 6, -56, 1
[3:13] QA HUD - Final 20060428: TRUE, 1, 456, 1
Mono Output:
[3:12] QA HUD - Final 20060428: FALSE, -38, 1, 0
[3:12] QA HUD - Final 20060428: FALSE, 1, 2, 0
[3:12] QA HUD - Final 20060428: TRUE, 1, 1, 1
[3:12] QA HUD - Final 20060428: TRUE, 11, 7, 3
[3:12] QA HUD - Final 20060428: TRUE, -38, 65, -37
[3:12] QA HUD - Final 20060428: TRUE, 6, -56, -50
[3:12] QA HUD - Final 20060428: TRUE, 1, 456, 457 |
Show » |
|
As Lex said, I seriously doubt they'll let this slide into release. 
Mono: Boolean AND (&&) and Boolean OR (||) were incorrectly mapped to the bitwise operators.
