アカウント名:
パスワード:
rireki1[100]; rireki2[100];
として、rireki1[99]まで使えば次にrireki2を使用し、rireki2[99]まで使えばrireki1の0~99を合計してrireki1[0]に入れ、rireki1[1]~rireki1[99]は0クリアする。 こうしておけば、積算金額を知りたい時には、全バッファ領域200個sumすれば算出できる。 また、今回利用金額を書き込むべき領域は、現在利用中バッファの金額が0になっている最初の所という条件で知る事ができる。 この手のカードでは、おそらく永久記憶にはフラッシュを使っているので、カウンタや積算金額などを毎回更新すると、特定の領域の書き換え回数が増えてしまい、寿命を縮めてしまうから、毎回特定領域を更新するような処理は避けているのではないかと予想。
この予想が正しければ、積算処理が走るのは200, 299, 398・・・となる。 この積算処理の中で、現在利用金額を保持している領域を破壊するようなバグがあったのかも。 この手の物はリソースが少ないので、RAM領域を使いまわしてたりする事も多いため、間違えて現在利用金額を保持する領域を使ってしまったとか、PICのようにバンク切替をするようなチップでバンクの切替忘れ(切替間違い)があったか・・・
そんな感じなのではないかと。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
規則性 (スコア:0, フレームのもと)
Re:規則性 (スコア:1)
Re:規則性 (スコア:0)
Re:規則性 (スコア:0)
199回までは別カウンタで回ってる? それも変な仕様だな。
やっぱ分からんわこれ。部門名みたいに明示的に200+99*n
とかいう判定条件が実装されてるのかなぁ。
Re:規則性 (スコア:2, 興味深い)
200になると前100個分を保存だかずらすだかして、次に200個使うまでバッファのポインタを前100個目にずらす。
この時にずらす位置を間違って、ずらした後に読込んだの値がずれる。
履歴があるのかどうか、ETCを使ってないから分からん。。。。
Re:規則性 (スコア:1)
次の100回を数えるためのカウンタの初期値だかを間違う。
それで99回目に再度・・・
どうだかな
Re:規則性 (スコア:4, 興味深い)
それを実現するために、2つの100回分の履歴領域を持ち、それを交互に利用する。
100個の領域のうち、最初の一つはバッファが溢れた場合には積算金額を保持する領域として使用。
rireki1[100];
rireki2[100];
として、rireki1[99]まで使えば次にrireki2を使用し、rireki2[99]まで使えばrireki1の0~99を合計してrireki1[0]に入れ、rireki1[1]~rireki1[99]は0クリアする。
こうしておけば、積算金額を知りたい時には、全バッファ領域200個sumすれば算出できる。
また、今回利用金額を書き込むべき領域は、現在利用中バッファの金額が0になっている最初の所という条件で知る事ができる。
この手のカードでは、おそらく永久記憶にはフラッシュを使っているので、カウンタや積算金額などを毎回更新すると、特定の領域の書き換え回数が増えてしまい、寿命を縮めてしまうから、毎回特定領域を更新するような処理は避けているのではないかと予想。
この予想が正しければ、積算処理が走るのは200, 299, 398・・・となる。
この積算処理の中で、現在利用金額を保持している領域を破壊するようなバグがあったのかも。
この手の物はリソースが少ないので、RAM領域を使いまわしてたりする事も多いため、間違えて現在利用金額を保持する領域を使ってしまったとか、PICのようにバンク切替をするようなチップでバンクの切替忘れ(切替間違い)があったか・・・
そんな感じなのではないかと。
Re:規則性 (スコア:0)
2. 溢れたら100個分追加で確保して繋げる。
3. 増やせなかったら機器の寿命という事にして有償交換させる。
4. たっだはずが99個しか追加できてない or 境界判定しくじった
って、こんな低レベルデバイスで動的確保してるとも考えづらいよなぁ..