記事によると
ボーイング787に248日問題、電源停止で制御不能の恐れ
http://japanese.engadget.com/2015/05/02/787-248-32bit/
・米国の連邦航空局が、ボーイング787に対して電源系を少なくとも248日ごとに再起動することを求める耐空性改善指令を出した
・ボーイング787の電源系を制御するソフトウェアに不具合があり、248日以上稼働し続けると動作が停止する恐れがあるという
この話題に対する反応
・桁あふれ問題がこんなとこにも。
・PC機器みたいな・・・
・ありがちなネタだな、だが事故る前で良かった
・従来の機種でこの問題は発生しなかったのだろうか？ もし発生していたとしたら、その際の対応記録/報告は活かされなかったのだろうか？
・ショボすぎる。
・32bit型のオーバーフローはいまなお古典ではない、ですね
248日 ‐ 通信用語の基礎知識
signedで32ビットの場合、最大で0x7fffffff(10進数で2147483647)までを扱うことができる。
これを10ミリ秒単位で扱うと、21474836470ミリ秒、つまり248日13時間13分56秒470ミリ秒までを扱えることになるが、これを超えるとオーバーフローする。
起動後に0からカウントを始めたとすると、この時間が過ぎた時にタイマーイベントは誤動作を始め、システムは、停止したり誤動作をする。
従って、この問題のあるシステムでは、248日以上の連続稼動が出来ない。
NTT東日本とNTT西日本のひかり電話用VoIPアダプタ(PR-200NE、RT-200NE、RV-230NE、AD-200NE)に、この問題があったことが知られている。
航空機でも248日問題が
飛行中に問題が発生してたらと思うと怖すぎる
【Amazon.co.jp限定】ストライクウィッチーズ Operation Victory Arrow vol.3 アルンヘムの橋 限定版 (後日談ドラマCD「ミッドナイト・イン・パ・ド・カレー」付き)[Blu-ray]posted with amazlet at 15.05.03KADOKAWA / 角川書店 (2015-07-31)
売り上げランキング: 2
【Amazon.co.jp限定】コードギアス 亡国のアキト 第3章 (初回限定版)(オリジナル描き下ろし絵柄収納BOX付) [Blu-ray]posted with amazlet at 15.05.03バンダイビジュアル (2015-06-26)
売り上げランキング: 17
![【Amazon.co.jp限定】ストライクウィッチーズ Operation Victory Arrow vol.3 アルンヘムの橋 限定版 (後日談ドラマCD「ミッドナイト・イン・パ・ド・カレー」付き)[Blu-ray]](http://ecx.images-amazon.com/images/I/51WYr11kxHL._SL160_.jpg)
![【Amazon.co.jp限定】コードギアス 亡国のアキト 第3章 (初回限定版)(オリジナル描き下ろし絵柄収納BOX付) [Blu-ray]](http://ecx.images-amazon.com/images/I/51KK14BpAPL._SL160_.jpg)
とりあえず直るまでそのまま運行しますよ
政府専用機、エアバスも導入しましょ
情弱は飛行機なんて乗らなくていいwww
2000年たいした事無かったじゃんという変な安心感（＝予算でない）があるから余計に
莫大な損失になるな！
エアバスは設計思想がノーサンキュー
メンテの時に落とせばいいし、大概それより短い期間で整備で再起動やってるだろうとはいえ
今回のはちょうどその半分の248日。なんかシステム的に重要な意味がある数字なんだろうね。
と思うんだけど何で漏れた。これが仕様だということにするとしても、
制限事項として絶対に上げるしどういう開発してんだこれ。
テーブルの項目とかじゃなくて、処理のどっかで「暗黙の型変換」されて32bitに変換されたとかじゃね？（レビューで見落としやすい）
更にオーバーフローが発生しても不具合が必ず発生するわけでもないなら試験でも流出しないだろう
ただ、発生したら致命的すぎるので客がどう運用するか分からない以上対策する必要がある。
Windowsの497日問題で、点検やらで年1回以上必ず再起動するからとパッチ適用を見送ってたら、UPSで停電を乗り切られて踏んだことがある。完全に運用を制御出来ない以上、どこにとんでもない運用をする顧客が居るか分からない。
※45
特定の経過時間を得るために、ある2点のシステム起動経過時間の差を使ったりする。
例えばある処理の経過時間を図るのにシステム起動経過時間を使用していて、昔はOSが考慮してなくてオーバフローするなんてのがあった。今はそんなOSを見ることも無くなったけど、カウンタのサイズは有限(互換性確保のため、新規API以外は昔のlong型をせざるを得ない)なのでOS側では上限に達すると0に戻る(もしくは最大値で固定となる)ように仕様を変更した。
それを考慮せずにうっかり「(ある時に取得した経過時間 - 少し前に取得した経過時間) > 閾値」を終了条件とする処理を組み込んだりすると爆弾になる。