あるAnonymous Coward曰く、オンライン・チェスサイト「Chess.com」で、セッションを識別するためのゲームIDが32ビットで表現できる範囲を超えてしまったために32ビット版のアプリからアクセスできなくなってしまったという（Chess.com、Slashdot）。同サイトの掲示板に投稿された苦情によると、64ビットに対応していないiOS環境でゲームがプレイできなくなっているという。これを受けてChess.comのCEOは、「私は開発者ではないため問題の原因は説明できないが謝罪する」と述べ、対応を行うとした。
ログIDとお金はintで管理してはいけない (スコア:1)
って小さいころママから教わらなかったのかい？
Re:ログIDとお金はintで管理してはいけない (スコア:3)
DBのカラムは全部VARCHAR(65535)にしてるので無問題です！
Re: (スコア:0)
あとタイムスタンプ系だな。ミリ秒以下の単位でカウントアップするヤツは特に。
もっと言うと、小数演算で誤差が許されない場合はfloatでもdoubleでもダメ(丸め誤差や内部表現の誤差がある)。
Re: (スコア:0)
マイクロソフトのXACT(Windows用)もやらかしてて、1ヶ月くらい連続でアプリが動いていると
コールバックが発生しなくなるバグが
Re: (スコア:0)
497 日もんだいもある
Re: (スコア:0)
95は49.7日で不正動作してたっけ。
その後のWindowsでタイマが10ms刻みになったのって、やっぱり単純に32ビットのまま稼働時間を10倍に伸ばすためだったのか
Re: (スコア:0)
Re: (スコア:0)
「大丈夫！
この仕事は納品すれば終わりだし、メンテは別会社に投げる予定だから。
どうせその頃に対応するのは赤の他人で、俺たちじゃないから。
むしろソニータイマーを入れておいた方が、自分達の飯の種になるってもんさ。」
＃2000年問題、なにそれ美味しいの
Re: (スコア:0)
って小さいころママから教わらなかったのかい？
それはそれでいいけど、今回の問題とは別だな。
Re: (スコア:0)
int は常に16bitや32bitってわけじゃないぞ。
Re:ログIDとお金はintで管理してはいけない (スコア:1)
short 以上っていうのは決まってなかったっけ？
Re:ログIDとお金はintで管理してはいけない (スコア:1)
shortもまたchar以上としか決まっていないので。
8ビット≦char≦short≦int≦long＜long long
です。
なんと、8ビットより長いであることが仕様から読み取れるのはlong longだけなのです！？
ビット長が重要なら悩まずint_16tとかを使いましょう。
Re:ログIDとお金はintで管理してはいけない (スコア:1)
その関係式とは別に、
という関係があります。
おお、そうだったのですね。ありがとうございます。
すると心配しないといけないのは、shortが32ビットあるかもしれない、とかの方向だったのですね。
Re: (スコア:0)
ネトゲの経験値とか体力とかも32bitではやばい
Re:ログIDとお金はintで管理してはいけない (スコア:2)
そういうのはカンストさせればいいんだよ。
仕様で上限を制約できない値がヤバいという話。
Re: (スコア:0)
いや今回の話と同じでサービスが続く以上カンストするわけにいかない値だったりしますよ
Re:ログIDとお金はintで管理してはいけない (スコア:1)
いや、カンストはできる。
そうすることによって、サービス停止をしなくていいのなら。
サービスを停止せざるを得ないケースといっしょにしてはいけない。いましめ。
4294967296 (スコア:0)
ユーザーが４０億人もいたわけじゃないんだろ？
32bitアプリだとしても32bit以上の数値を扱えないわけじゃないんだが
32bit云々は言い訳じゃないのか
Re: (スコア:0)
セッションなので、最悪アプリを起動しただけで1カウント、1回プレイ開始すればカウントアップですよ。
Re: (スコア:0)
おそらく40億回は累計のアクセス。
32bit云々は言い訳というより利用者がバグの原因を推測したもの。32bitアプリケーションだと標準では32bitの整数を扱うようになっているために注意しないとこういうことが起きる。もちろん32bitより大きい整数を扱うように指定すれば動くようになる。
# 失敗の原因の解説を言い訳と断じてしまうのはよくないこともあると思いますっ!
Re: (スコア:0)
signedなら更に半分
Re: (スコア:0)
言い訳をすることにどんなメリットがあると想像したのかお聞きしたい。
Re: (スコア:0)
Appleのせいにできる
Re: (スコア:0)
ああなんか元コメの意図が分かった。32bit版の仕様だから仕方ないという弁明と取ったのか。バグの原因の説明じゃなくて。
神の領域へ (スコア:0)
よくあるじゃないか
能力が人間の限界を越えて他人からは見たり触れられない存在になってしまうことが
# そんなにはありません
Re:神の領域へ (スコア:1)
ああ、誰からも話しかけられないのはそのせいか!
Re: (スコア:0)
オーバーフローすると、自己同一性を喪失して別の存在になってしまうという事ですね。
32bitアプリでも64bit整数は使えるだろ (スコア:0)
> ゲームIDが32ビットで表現できる範囲を超えてしまったために32ビット版のアプリからアクセスできなくなってしまった
ちょっと何言ってるのかわからない。(SwiftやObjective Cは知らんがC++で言うと)uint64_tを使うべきところでなぜかuintptr_tを使ってたってこと?
Re:32bitアプリでも64bit整数は使えるだろ (スコア:1)
簡素にint(or unsined int)で書いちゃってて、それが、ということかな
直す分には64bit(uint64_t)にするのは難しくないけど
DBとかにも32bitで波及していると修正範囲デカそうだな...
# 64bitアプリは平気だから、それはないか
M-FalconSky (暑いか寒い)
Re: (スコア:0)
もっとしょうもない、何処かでatoiしてて32bit環境だと溢れるように→エラーみたいなパターンかと。
Re: (スコア:0)
iOSはLP64らしいので多分long型を使ってしまっているのではないかと思います
Re: (スコア:0)
Swiftの場合はIntを使っていたという可能性も。
> On 32-bit platforms, Int is the same size as Int32, and on 64-bit platforms, Int is the same size as Int64.
Re: (スコア:0)
32ビットC/C++コンパイラでINT64とかUINT64とかって型ができたのはわりと最近の話でな。
それ以前はWin32 APIでもSetFilePointer()では独立した32ビット変数を２個渡したり、
別のAPIではLARGE_INTEGERなどという構造体を使ったりしてたもんじゃ。
＃などと昔話をする年寄りの図
iOS11対応端末 (スコア:0)
iPhoneに限っても32bitから移行できない端末は5%程度だし
仮に対応しなくともあまり騒ぎにならないんじゃないかと
Re: (スコア:0)
> iPhoneに限っても32bitから移行できない端末は5%程度だし
AppleのiOSアップデート率とかiOSバージョンごとの稼働率、iOS端末ごとの稼働率とかは
「直近3か月くらいでAppStoreにアクセスした端末だけが対象」なので
古い端末で安定した環境を作りiOSのアップデートもしないアプリのアップデートもしないという人が
母数から除外されてしまっている
それどころかiOSアップデートで動作がおかしくなったり互換性がなくなったりして
アップデートして困った人がAppStoreを見るほど、アップデート率が現実を無視して高くなっていくおかしなことをやってる
そんな人はいないんじゃないかなぁ？ (スコア:0)
「古い端末で安定した環境を作りiOSのアップデートもしないアプリのアップデートもしないという人が」
ほんとに実在するのかな？
実際どれくらいの人数/台数が該当するのか、どうすれば知ることができるのだろうか。
...しかも、そんな環境なのに「オンライン・チェスサイト」にアクセスしてゲームを楽しんでいた人なんて....
Re: (スコア:0)
あなたの親や祖父母がスマホ使ってたら、端末買ってから一度もアップデートしていない層も結構いるんですよ
Re: (スコア:0)
AppleのiOSアップデート率とかiOSバージョンごとの稼働率、iOS端末ごとの稼働率とかは
「直近3か月くらいでAppStoreにアクセスした端末だけが対象」なので
古い端末で安定した環境を作りiOSのアップデートもしないアプリのアップデートもしないという人が
母数から除外されてしまっている
ユーザーが明示的にApp storeを起動しなくても、iOSはApp storeにアクセスして、アップデート可能な
アプリがあるかをチェックしている。
だから「iOSのアップデートもしないアプリのアップデートもしないという人が母数から除外されてしまっている」
などということはない。
Re: (スコア:0)
> ユーザーが明示的にApp storeを起動しなくても、iOSはApp storeにアクセスして、アップデート可能な
> アプリがあるかをチェックしている。
違う
アプリ更新の通知はiOS側ではなくAppleのサーバー側でチェックして
iOSには（iOS端末にインストール済みフラグがついており、かつオンライン側で更新があれば）通知だけ来る
なのでAppleのサーバー側の処理がおかしくなると、
iOS端末上ですでに更新したアプリなのに、同バージョンが新しく公開されたという通知がサーバー側から何通も来たりする
「AppStoreにアクセスする」を満たすには通知を見たユーザーがiOS端末上でAppStoreを起動する必要がある
Re: (スコア:0)
もともとの
>iPhoneに限っても32bitから移行できない端末は5%
というデータのソースと、
デベロッパーに向けた、AppStoreでアプリを探しているユーザーのiOSバージョン比率データ
https://developer.apple.com/support/app-store/ [apple.com]
とを混同してるんでは？ （いや、元の5%というデータのソースはがどこかは知らないけど）
それから、
>アプリ更新の通知はiOS側ではなくAppleのサーバー側でチェックして
というソースはあるの？
これだと、アプリ自動更新スイッチをオフにしていても、Appleのサーバー側でのチェックと端末への通知が行われることになるけど。
Re: (スコア:0)
> 「AppStoreにアクセスする」を満たすには通知を見たユーザーがiOS端末上でAppStoreを起動する必要がある
いやいやｗ
Apple IDのパスワードを変更してみれば一発でわかるように、iPhoneでApp Storeを起動していない状態でも、
App storeにアクセスできないからアカウント設定を正しくしろというポップアップが出てくるよ。
妄想お疲れさんｗｗｗ
Re: (スコア:0)
> App storeにアクセスできないからアカウント設定を正しくしろというポップアップが出てくるよ。
それはそちらの論拠にまったく該当しない
そもそもオンライン側のパスワードを変更したときに端末側のパスワード設定も再設定させるのは、
端末を紛失盗難したさいに緊急でオンライン側でパスワードを変えたとき、
端末側でもパスワードを再設定させることで安全性を確保するためのもの
上記目的がない前提でいえば、
AppleIDのパスワードを変えたときにすでにAppleIDに対するアクセス許可トークンを持ってるiOS端末で
パスワードの再設定をする必要はそもそも存在しない
（ただし、
Re: (スコア:0)
実際の挙動としては、Appleのサーバから
「オンライン側でパスワードが変わっているのでいったんお前（端末）からのアクセスはRevokeする」
と通知されるだけの挙動
ところがApple IDのパスワードを一旦変更した後、再び元のパスワードに戻しておくと、端末の方は何も言ってこないんですね～ｗ
君の「理論」だと変更がかかったらその時点で
「オンライン側でパスワードが変わっているのでいったんお前（端末）からのアクセスはRevokeする」
と通知される
のだから、とにかくアクセスできなくなるんじゃないの？
とうとう妄想が過ぎてAndroidやiOSの仕様を自分で作るまでに至ったかｗ
iOSの設定にはApp storeアプリが自動でダウンロードしたりアップデートしたり
するかどうかを設定する
Re: (スコア:0)
端末にシリアルナンバーのないグーグルの場合一台に複数のグーグルプレイアカウントを登録している端末が重複してカウントされているということだな。
Re: (スコア:0)
こういう基本も知らない、レベルの発言だらけですがね。ここ。
Re: (スコア:0)
オンラインになってればユーザがアップストアにアクセスしなくてもAppstoreAppが勝手にアプリの更新を見に行くのでカウントはされるはずですよ。
そんなこと言われてもどうすりゃいいのさ？ (スコア:0)
MySQLｴｴｴｴｴ…
おい、そこで笑ってるぽすぐれ使い
君のserialだって何気にヤバいんだぜ？
# idはbigintのauto_increment、あるいはbigserialで振る時代へ・・・・・
Re:そんなこと言われてもどうすりゃいいのさ？ (スコア:1)
> # idはbigintのauto_increment、あるいはbigserialで振る時代へ・・・・・
idを意味する列は全部guidって設計もありますね。
これならうっかり関連のないテーブルのid列と結合してしまい意味不明な結果になるバグも防げます。（0件になるから）
連番にならないので前後の比較がしたいときやアプリケーション上の「番号」がほしいときは別の列が追加で必要になる欠点はありますが。
Re:そんなこと言われてもどうすりゃいいのさ？ (スコア:1)
もう元のストーリーとはかなり外れる話になるけど
ワイ「「id」って名前はいろんな所で使われるから（HTMLのid属性とか）あまり被らない名前にしたいンゴねえ・・・
せや！rownumにしたろ！」
OracleのROWNUM「よろしくニキーｗｗｗｗ」
ワイ「あああああああ！（ﾌﾞﾘﾌﾞﾘﾌﾞﾘﾌﾞﾘ」
ってなった事がある。後始末大変だった。
Re:そんなこと言われてもどうすりゃいいのさ？ (スコア:1)
10年くらい昔からとっくにそうしてるぜ。
身内用アプリだけど、だからこそストレージの心配なんかないからな。
むしろどうしてそうしてないのか？