OpenSIM全般のバグ(かどうかもわからない)かもしれませんが
http://wiki.secondlife.com/wiki/Unix2StampLst
を動かそうとして 5 行目が SL とは違う評価になることに気づきました
vIntDat %= 126230400
によって余剰が代入されますが
つづくvIntDat / 126230400のとき
SLではまだ代入されておらず
OpenSIMではすでに代入されています
%= の順位は低いが () があるので
OpenSIMの動作のほうが妥当なようにも見えますが
同じ動作を目指しているのであればということで報告しておきます
情報ありがとうございます.
情報共有が目的であれば良いのですが,もし修正を希望している場合は,このレベルのバグはこちらでは対応不可能ですので,直接OpenSimのバグトラッカーに投げると良いと思います.
http://opensimulator.org/mantis/main_page.php
よろしくお願いします.
情報共有目的で書いてます。
たぶん、知世さんもそのつもりだと思います。
次のスクリプトをSecondlifeにLinden 純正ビュアーでログインした環境と、
OpenSim 0.8.2.1 Release REL-0.8.2.1 に Firestormビュアーでログインした環境とで
実行してみました。
default
{
state_entry()
{
integer a;
integer b;
a = 10;
b = (a %= 3) + a;
llOwnerSay("a=" + (string)b);
}
}
結果は、知世さんの指摘の通り、
Secondlifeでは 「a=11」
OpenSimでは 「a=2」
が表示されました。
ですが、これはバグというより、式の評価順序という実装に依存したコードを書いてしまった為の挙動だと思います。 「+」などの二項演算子の場合、
式1 + 式2
と式を書いた場合、式1を評価(計算)してから、式2を評価するのか、逆なのかは、実装依存であり厳密には規定されていません。また、コンパイラなどの処理系のオプティマイズ(最適化)によっては、結果が同じであれば内部的に演算の順序を逆にする事もあります。
特に、このように演算してる途中の変数を変更するような代入演算子やインクリメント・デクリメント演算子(++,--)の場合、このような副作用が起こりがちになります。
昔、C言語でも処理系によって、似たようなことは経験しています(Turbo-C と MSCとでは挙動がちがうとか...、オプティマイズレベルを変えると結果がちがうとか...)。たとえば、次のC言語のコードは、どのような値が表示されるかは、処理系により違いがでたと記憶してます。
int a = 1;
printf("a=%d\n", a++ + a++);
いずれにしろ、バグというよりは、そのような処理系依存の曖昧性がのこるコードは書いちゃダメ、ってことなんだと思います。