コンテンツにスキップ

整数オーバーフロー

出典: フリー百科事典『ウィキペディア（Wikipedia）』
整数オーバーフローは、機械的な現象であるオドメーター（走行距離計）の桁あふれによって実証できる。すべての桁が最大値の9に設定されており、白い桁が次に増加すると、桁上がりの連鎖が発生してすべての桁が0に設定されるが、1に変更するための上位桁（1,000,000の位）が存在しないため、カウンターはゼロにリセットされる。これは「飽和」とは対照的な「ラッピング」（巻き戻り）である。

整数オーバーフロー（せいすうオーバーフロー、英語: integer overflow）とは、コンピュータプログラミングにおいて、整数に対する算術演算によって、その結果を格納するために割り当てられた空間で表現可能な範囲外の数値（最大値より大きい、または最小値より小さい）を作成しようとしたときに発生する現象である。

現代の計算における整数の算術演算のほとんどは整数のバイナリ（二進法）表現を使用しているが、十進法表現も存在する。本記事では主にバイナリ表現について扱うが、他のケースでも同様の考慮事項が当てはまる。

コンピュータ内でビットパターンとして表現される整数は、「符号なし整数」（値が0からある最大値まで）または「符号あり整数」（値が正または負）のいずれかとして解釈できる。最も一般的には、符号あり整数は2の補数形式で表現され、最上位ビットが符号（0なら+、1なら-）として解釈される。

例えば、32ビットワードにおいて、符号なし整数の値は0から232-1 = 4,294,967,295までであるが、符号あり整数の値は-231 = -2,147,483,648から231-1 = 2,147,483,647までである。

整数オーバーフローが発生すると、実行された演算が示す数学的な値とは異なる値が格納される結果となる。最も一般的には、結果のビットパターンは、演算が2W（Wはビット単位のワードサイズ）を法（modulo）として実行された場合と同じになる。また、演算によってオーバーフローが発生したことを示すフラグが設定（セット）または解除（アンセット）されることもある。GPUやデジタルシグナルプロセッサ（DSP）などの一部のプロセッサでは、飽和演算をサポートしており、オーバーフローした結果は「クランプ」される。すなわち、結果が最小値を下回る場合は表現可能な範囲の最小値に、最大値を上回る場合は最大値に設定される。

プログラマが予期していない場合、整数オーバーフローはプログラムの信頼性やセキュリティに悪影響を及ぼす可能性がある。共通脆弱性タイプでは、CWE-190に分類される[1]。

発生原因

[編集]

整数オーバーフローは、整数に対する算術演算が、指定された桁数で表現できる範囲外の数値を作成しようとしたときに発生する。コンピュータプログラミングの文脈では整数はバイナリであるが、桁（ポジション）が制限されている場合、どのような位取り記数法のシステムであっても算術演算の結果が無効になる可能性がある。オドメーターの例で示したように、十進法を使用し、6桁（数字）の制約がある場合、次の演算は無効な結果となる：999999 + 1。同様に、4桁（ビット）に制限されたバイナリシステムでは、次の演算が無効な結果となる：1111 + 1。どちらの例でも、結果は制約によって表現可能な範囲を超える値となる。この問題を別の視点から見ると、最上位の桁の演算において桁上がりが発生し、割り当てが必要な別の桁/ビットを必要とするため、制約が破られるということである。

コンピュータプログラミングにおけるすべての整数には、最大値と最小値の制約がある。範囲を決定する主な要因は、ビットの割り当てと、それが符号付きか符号なしかである。標準的な整数は、プラットフォームやプログラミング言語によって異なる。標準よりも小さい、あるいは大きい整数の表現も可能である。例としては、それぞれショート整数やロング整数がある。任意精度演算も存在するが、これはあらかじめ設定された精度や利用可能なシステムメモリによって制限される。

一般的な整数の境界
ビット別名[注釈 1]範囲符号付きの範囲[注釈 2]符号なしの範囲
8-bit byte、[2][注釈 3] sbyte、[3] octet 28 − 1-128[4]0[5]
127[6]255[7]
16-bit word、short、int16、[8] uint16[9] 216 − 1−32,768[10]0[11]
32,767[12]65,535[13]
32-bit[注釈 4] int32、[14] uint32[15] 232 − 1-2,147,483,648[16]0[17]
2147483647[18]4,294,967,295[19]
64-bit[注釈 5] int64、[20] uint64[21] 264 − 1−9,223,372,036,854,775,808[22]0[23]
9,223,372,036,854,775,807[24]18,446,744,073,709,551,615[25]
128-bit int128、[26] uint128[27] 2128 − 1−170,141,183,460,469,231,731,687,303,715,884,105,7280
170,141,183,460,469,231,731,687,303,715,884,105,727340,282,366,920,938,463,463,374,607,431,768,211,455
  1. ↑ 整数（int）データ型は通常、2の補数を使用するため符号付きである。「u」接頭辞は符号なしの実装を指定する。
  2. ↑ 符号付きの範囲は2の補数を仮定している。
  3. ↑ byteデータ型は通常、デフォルトで符号なしである。「s」接頭辞は符号付きの実装を指定する。
  4. ↑ パーソナルコンピュータにおいて最も一般的（2005年現在）。
  5. ↑ パーソナルコンピュータにおいて最も一般的（2025年現在）。

符号なし算術演算がNビット整数の最大値を超える結果を生成すると、オーバーフローによって結果は2のN乗を法とする剰余に減じられ、結果の最下位ビットのみが保持される。これは事実上ラップアラウンドを引き起こす。

特に、2つの整数を乗算または加算すると、予想外に小さな値になる可能性があり、小さな整数から減算すると、大きな正の値にラップする可能性がある（例えば、8ビット整数の加算 255 + 2 の結果は1となり、これは257 mod 28である。同様に、減算 0 − 1 の結果は255となり、これは−1の2の補数表現である）。

このようなラップアラウンドは、セキュリティ上の損害を引き起こす可能性がある。オーバーフローした値がバッファ確保のためのバイト数として使用されると、バッファが予想外に小さく割り当てられ、潜在的にバッファオーバーフローにつながる可能性がある。バッファの使用方法によっては、これがさらに任意のコード実行を引き起こす恐れがある。

変数が符号あり整数型の場合、プログラムはその変数が常に正の値を保持していると仮定することがある。整数オーバーフローによって値がラップして負になると、プログラムの仮定に違反し、予期しない動作につながる可能性がある（例えば、8ビット整数の加算 127 + 1 の結果は−128となり、これは128の2の補数である）。（この特定の問題の解決策は、プログラムが負になることはないと期待・仮定する値に対しては、符号なし整数型を使用することである。）

フラグ

[編集]

現代のコンピュータの多くは、加算や減算の演算によるオーバーフロー発生時にセットされる専用のプロセッサフラグを備えている。

キャリーフラグは、加算または減算の結果を符号なし数値として考慮した場合に、指定されたビット数に収まらない場合にセットされる。これは、最上位ビットからの桁上がりまたはボローを伴うオーバーフローを示す。

オーバーフローフラグは、符号あり数値の加算または減算の結果が、オペランドの符号から予測される符号と異なる場合（例：2つの正の数を加算して負の結果になる場合）にセットされる。これはオーバーフローが発生し、2の補数形式で表現された符号付きの結果が指定されたビット数に収まらないことを示す。ADD命令の場合、これは符号ビットへのキャリーと符号ビットからのキャリーが異なっていたことを意味する。

定義のバリエーションと曖昧さ

[編集]

符号なし型の場合、演算の理想的な結果がその型の表現可能な範囲外であり、返される結果がラッピングによって得られるとき、この事象は一般にオーバーフローと定義される。対照的に、C言語の標準規格では、この事象はオーバーフローではないと定義しており、「符号なしオペランドを含む計算は決してオーバーフローしない」と述べている[28]。この説明は、標準規格が符号なし整数の算術を、ワードサイズをWとしたときの2Wを法とする算術であると定義しているためである。これは数学的に明確に定義されており、表現可能な値のみを持つ。

整数演算の理想的な結果がその型の表現可能な範囲外であり、返される結果がクランプによって得られるとき、この事象は一般に飽和と定義される。飽和をオーバーフローとするか否かは、使用法によって異なる。曖昧さを排除するために、ラッピングオーバーフロー[29]および飽和オーバーフロー[30]という用語を使用することができる。

整数演算が表現可能な最小値よりも小さい値を生成するケースは、時として「整数アンダーフロー」と呼ばれることもあるが、最も一般的にはオーバーフローの一種として知られている[31]。この用法は、浮動小数点値が0に近すぎることを指す浮動小数点アンダーフローとは全く異なる。

一貫性のない動作

[編集]

オーバーフロー発生時の動作は、すべての状況において一貫しているとは限らない。例えば、Rust言語では、ユーザーに選択と制御を与えるための機能が提供されている一方で、基本的な数学演算子の使用における動作は自然に固定されている。しかし、この固定された動作は、デバッグモードでビルドされたプログラムとリリースモードでビルドされたプログラムとで異なる[32]。C言語では、符号なし整数のオーバーフローはラップアラウンドするように定義されているが、符号あり整数のオーバーフローは未定義動作を引き起こす。

対処法

[編集]
各種プログラミング言語における整数オーバーフロー処理
言語 符号なし整数 符号あり整数
Ada型の法（modulus）で剰余raise Constraint_Error
C, C++2の冪乗で剰余未定義動作
C#uncheckedコンテキストでは2の冪乗で剰余; checkedコンテキストではSystem.OverflowExceptionが発生[33]
Java2の冪乗で剰余 (charがJavaにおける唯一の符号なしプリミティブ型)2の冪乗で剰余
JavaScript新しいBigIntを除き、すべての数値は倍精度浮動小数点数である
MATLAB組み込み整数は飽和する。固定小数点整数はラップまたは飽和するように設定可能
Python 2N/Along型 (bigint) に変換
SchemeN/AbigNumに変換
Simulinkラップまたは飽和するように設定可能
SmalltalkN/ALargeIntegerに変換
Swift特別なオーバーフロー演算子を使用しない限りエラーとなる[34]

検出

[編集]

Cコンパイラでは、実行時のオーバーフロー検出実装であるUBSan（未定義動作サニタイザー）が利用可能である。

Java 8では、オーバーロードされたメソッド、例えばMath.addExact(int, int)があり、これはオーバーフローの場合にArithmeticExceptionをスローする。

CERTは、実行時エラー処理を使用してC/C++における整数オーバーフローと切り捨てを排除するための、ほぼ自動化されたメカニズムであるAIR (As-if Infinitely Ranged) 整数モデルを開発した[35]。

回避

[編集]

計算され格納される可能性のあるすべての値を格納できる十分な大きさのデータ型を持つ変数を割り当てることで、オーバーフローを常に回避できる。プログラミング言語や環境が提供する使用可能なスペースや固定データ型が限られており、十分なサイズで変数を防御的に割り当てることができない場合でも、演算の順序を慎重に決め、オペランドを事前にチェックすることで、結果が決して格納可能な範囲を超えないことを先験的に保証できる場合が多い。静的解析ツール、形式的検証、契約プログラミング技術を使用することで、オーバーフローが誤って発生しないことをより確信を持って堅牢に保証できる。

ハンドリング

[編集]

オーバーフローが発生する可能性があると予想される場合、プログラムにテストを挿入して、いつ発生するか、または発生しようとしているかを検出し、それを緩和するための他の処理を行うことができる。例えば、ユーザー入力から計算された重要な結果がオーバーフローする場合、プログラムは無効なオーバーフロー入力で処理を進めて結果として誤動作するのではなく、停止して入力を拒否し、ユーザーに別の入力を求めることができる。

CPUは通常、レジスタサイズより大きな数値の加算をサポートするために、ステータスビットを使用してこれを検出する方法を持っている。この技術は多倍長演算と呼ばれる。したがって、1バイトより広いオペランドに対してバイト単位の加算を行うことが可能である。まず下位バイトを加算して結果を格納し、オーバーフローをチェックする。次に上位バイトを加算し、必要に応じて下位バイトからの「キャリー」を加算して結果を格納する。

計算のオーバーフローの可能性を処理する際、計算を行う「前」にチェックを行うか（オーバーフローが発生するかどうかを判断するため）、計算の「後」にチェックを行うか（結果の値に基づいて発生した可能性が高いかどうかを検討するため）の選択を迫られることがある。一部の実装では整数オーバーフローでトラップ条件を生成する場合があるため、最も移植性の高いプログラムは、オーバーフローする可能性のある演算を実行する前にテストを行う。

プログラミング言語のサポート

[編集]

プログラミング言語は、偶発的なオーバーフローに対するさまざまな緩和策を実装している。Adaや関数型言語の一部のバリアントは、オーバーフロー時に例外条件をトリガーするが、Python（2.4以降）は、数値の内部表現をその増加に合わせてシームレスに変換し、最終的にlongとして表現する。この能力は利用可能なメモリによってのみ制限される[36]。

任意精度演算と型安全性をネイティブにサポートする言語（Python、Smalltalk、Common Lispなど）では、オーバーフローが発生すると数値が自動的により大きなサイズに昇格するか、範囲制約が存在する場合は例外がスロー（条件が通知）される。このような言語を使用することは、この問題を緩和するのに役立つ。しかし、そのような言語であっても、整数オーバーフローが発生する可能性のある状況は依然として存在する。例としては、プロファイラによってボトルネックと見なされたコードパスの明示的な最適化がある。Common Lispの場合、変数に格納される整数のサイズがマシンサイズのワード（fixnum）に収まるとプログラマが確信できる場合、型注釈する明示的な宣言を使用し、整数の多倍長への切り替えを抑制させることが可能だが[37]、これは特定のコードブロックに対して型安全性レベルをゼロに下げることで可能になる[38][39][40][41][42]。前述のように、これは意図されたチューニングであり、オーバーフローやラップアラウンドを目的として型注釈を使用することはない（なお、この場合コードは未定義動作となる）。

C言語のような古い言語とは対照的に、Rustなどの一部の新しい言語は、オーバーフローをどのように処理するかをケースバイケースでユーザーが簡単に選択および検出できる組み込み関数を提供している。Rustでは、基本的な数学演算子の使用には当然そのような柔軟性はないが、ユーザーは代わりに整数プリミティブ型ごとに提供される一連のメソッドを介して計算を実行できる。これらのメソッドは、チェック付き演算（戻り値の型を介してオーバーフローが発生したかどうかを示す）、チェックなし演算、ラッピングを実行する演算、または数値境界で飽和を実行する演算など、いくつかの選択肢をユーザーに提供する。

飽和演算

[編集]

コンピュータグラフィックスや信号処理では、0から1、または-1から1の範囲のデータを扱うのが一般的である。例えば、0が黒、1が白を表し、その間の値がグレーの濃淡を表すグレースケール画像を考える。サポートしたい演算の一つに、すべてのピクセルに定数を掛けて画像を明るくするものがある。飽和演算を使用すると、オーバーフローを心配することなく、すべてのピクセルにその定数を盲目的に掛けることができる。これは、1より大きいすべてのピクセル（つまり「白より明るい」）は単に白になり、「黒より暗い」すべての値は単に黒になるという、妥当な結果に固執することで実現される。

実例

[編集]

予期せぬ算術オーバーフローは、プログラムエラーのかなり一般的な原因である。このようなオーバーフローのバグは発見や診断が難しい場合がある。なぜなら、検証テストで使用される可能性が低い非常に大きな入力データセットに対してのみ発現することがあるためである。

多くの探索アルゴリズムで行われるように、2つの数値を加算して2で割ることで算術平均を取る方法は、合計（結果の平均ではない）が表現するには大きすぎてオーバーフローする場合にエラーを引き起こす[43]。

いわゆる2038年問題は、UNIXにおける時間（UNIX時間）を表現する秒カウンタ型である「time_t型」が、古いシステムでは32bit signed int型として実装されているために発生するオーバーフローに起因するもので、演算内容によっては2038年を待たずに問題が表面化するものもある。

1985年から1987年にかけて、Therac-25放射線治療装置における算術オーバーフローは、ハードウェアの安全制御の欠如と相まって、放射線過剰投与による少なくとも6人の死亡事故を引き起こした[44]。

1996年のアリアン5ロケットの初飛行（アリアン5フライト501）の墜落の主な原因は、エンジンのステアリングソフトウェアにおける処理されていない算術オーバーフローであった[45]。このソフトウェアは以前の多くの飛行で使用されていたためバグはないと考えられていたが、それらはアリアン5よりも加速度が低い小型のロケットを使用していた。苛立たしいことに、オーバーフローエラーが発生したソフトウェア部分は、ロケットを故障させた時点ではアリアン5で実行する必要さえなかった。それは、アリアン5用に適応された際にソフトウェアに残っていた、小型の前身ロケット用の打ち上げ体制プロセスであった。さらに、失敗の真の原因は、オーバーフローが検出されたときのソフトウェアの対処方法に関する工学仕様の欠陥であった。診断ダンプをバスに出力したが、これは開発中のソフトウェアテストではテスト機器に接続されていたものの、飛行中はロケットのステアリングモーターに接続されていた。データダンプによってエンジンノズルが片側に激しく駆動され、ロケットは空力的制御を失い、空中での急速な分解を招いた[46]。

Microsoft Macro Assembler バージョン 1.00 (1981) のスタック設定コードにある整数オーバーフローのバグにより、512 KiBを超えるメモリを搭載した一部の構成では実行できない。

Microsoft Macro Assemblerバージョン1.00、およびおそらく同じPascalコンパイラでビルドされた他のすべてのプログラムには、スタック設定コードに整数オーバーフローと符号属性のエラーがあり、512 KiBを超えるメモリを持ついくつかの一般的な構成の下では、新しいMS-DOSマシンやエミュレータでの実行が妨げられる。プログラムはハングするか、エラーメッセージを表示して終了する[47]。

2015年4月30日、米国連邦航空局（FAA）は、電力損失やラムエア・タービンの展開につながる可能性のある整数オーバーフローを回避するために、ボーイング787の運航者に対して電気システムを定期的にリセットするよう命じると発表した。ボーイングは第4四半期にソフトウェアアップデートを展開した[48]。欧州航空安全機関も2015年5月4日にこれに続いた[49]。このエラーは231百分の一秒（約249日）後に発生し、32ビットの符号付き整数を示している。

2016年8月、Resorts Worldカジノにあるカジノマシンが、オーバーフローバグの結果として$42,949,672.76の賞金チケットを印刷した。カジノ側はこれを誤動作と呼び、支払いを拒否した。彼らの主張は、マシンの最大支払額は$10,000であると明確に記載されており、それを超える賞金はプログラミングのバグの結果でなければならないというものであった。New York State Gaming Commissionはカジノ側に有利な判決を下した[50]。

ビデオゲーム

[編集]

ファミコン版『スーパーマリオブラザーズ』では、保存される残機数は符号付きバイト（-128から127の範囲）であり、プレイヤーは安全に127機まで持つことができるが、128機目に達するとカウンタが0機にロールオーバーし（数字カウンタはこれが発生する前にグリッチ表示になるが）、カウントを停止する。この状態でプレイヤーが死ぬと即座にゲームオーバーとなる。

アーケードゲーム『ドンキーコング』では、時間/ボーナス計算における整数オーバーフローのため、レベル22を超えて進むことができない。このゲームは、ユーザーがいるレベル番号に10を掛け、40を加えることで時間/ボーナスを決定する。レベル22に達すると、時間/ボーナスの数値は260になるが、これは8ビットの256値レジスタには大きすぎるため、値4にオーバーフローする。

『パックマン』における「キルスクリーン」という現象は整数オーバーフローが原因である[51]。

『Minecraft』では、Java EditionのInfdev開発期間からBeta 1.7.3まで存在した「Far Lands（最果ての地）」やBedrock Editionで整数オーバーフローが発生していたが、その後修正された[52]。

関連項目

[編集]

外部リンク

[編集]

脚注

[編集]
  1. ↑ “CWE-190”. jvndb.jvn.jp. 2026年1月21日閲覧。
  2. ↑ “.NET Byte Struct”. Microsoft. 2026年1月21日閲覧。
  3. ↑ “.NET SByte Struct”. Microsoft. 2026年1月21日閲覧。
  4. ↑ “.NET SByte.MinValue Field”. Microsoft. 2026年1月21日閲覧。
  5. ↑ “.NET Byte.MinValue Field”. Microsoft. 2026年1月21日閲覧。
  6. ↑ “.NET SByte.MaxValue Field”. Microsoft. 2026年1月21日閲覧。
  7. ↑ “.NET Byte.MaxValue Field”. Microsoft. 2026年1月21日閲覧。
  8. ↑ “.NET Int16 Struct”. Microsoft. 2026年1月21日閲覧。
  9. ↑ “.NET UInt16 Struct”. Microsoft. 2026年1月21日閲覧。
  10. ↑ “.NET Int16.MinValue Field”. Microsoft. 2026年1月21日閲覧。
  11. ↑ “.NET UInt16.MinValue Field”. Microsoft. 2026年1月21日閲覧。
  12. ↑ “.NET Int16.MaxValue Field”. Microsoft. 2026年1月21日閲覧。
  13. ↑ “.NET UInt16.MaxValue Field”. Microsoft. 2026年1月21日閲覧。
  14. ↑ “.NET Int32 Struct”. Microsoft. 2026年1月21日閲覧。
  15. ↑ “.NET UInt32 Struct”. Microsoft. 2026年1月21日閲覧。
  16. ↑ “.NET Int32.MinValue Field”. Microsoft. 2026年1月21日閲覧。
  17. ↑ “.NET UInt32.MinValue Field”. Microsoft. 2026年1月21日閲覧。
  18. ↑ “.NET Int32.MaxValue Field”. Microsoft. 2026年1月21日閲覧。
  19. ↑ “.NET UInt32.MaxValue Field”. Microsoft. 2026年1月21日閲覧。
  20. ↑ “.NET Int64 Struct”. Microsoft. 2026年1月21日閲覧。
  21. ↑ “.NET UInt64 Struct”. Microsoft. 2026年1月21日閲覧。
  22. ↑ “.NET Int64.MinValue Field”. Microsoft. 2026年1月21日閲覧。
  23. ↑ “.NET UInt64.MinValue Field”. Microsoft. 2026年1月21日閲覧。
  24. ↑ “.NET Int64.MaxValue Field”. Microsoft. 2026年1月21日閲覧。
  25. ↑ “.NET UInt64.MaxValue Field”. Microsoft. 2026年1月21日閲覧。
  26. ↑ “.NET Int128 Struct”. Microsoft. 2026年1月21日閲覧。
  27. ↑ “.NET UInt128 Struct”. Microsoft. 2026年1月21日閲覧。
  28. ↑ ISO staff. “ISO/IEC 9899:2011 Information technology - Programming languages - C”. ANSI.org. 2026年1月21日閲覧。
  29. ↑ “Wrap on overflow - MATLAB & Simulink”. MathWorks. 2026年1月21日閲覧。
  30. ↑ “Saturate on overflow - MATLAB & Simulink”. MathWorks. 2026年1月21日閲覧。
  31. ↑ “CWE - CWE-191: Integer Underflow (Wrap or Wraparound) (3.1)”. cwe.mitre.org. 2026年1月21日閲覧。
  32. ↑ “Operator expressions - The Rust Reference”. Rust-lang.org. 2021年2月12日閲覧。
  33. ↑ BillWagner (2023年4月8日). “Checked and Unchecked (C# Reference)”. Microsoft. 2026年1月21日閲覧。
  34. ↑ (英語) The Swift Programming Language. Swift 2.1 Edition.. Apple Inc.. (2015-10-21)
  35. ↑ CERT. As-if Infinitely Ranged Integer Model (PDF) (Report). 2026年1月21日閲覧.
  36. ↑ “Python documentation”. Python Software Foundation. 2026年1月21日閲覧。
  37. ↑ “Declaration TYPE”. Common Lisp HyperSpec. 2026年1月21日閲覧。
  38. ↑ “Declaration OPTIMIZE”. Common Lisp HyperSpec. 2026年1月21日閲覧。
  39. ↑ Reddy, Abhishek (2008年8月22日). “Features of Common Lisp”. 2026年1月21日閲覧。
  40. ↑ Pierce, Benjamin C. (2002) (英語). Types and Programming Languages. MIT Press. ISBN 0-262-16209-1
  41. ↑ Wright, Andrew K.; Felleisen, Matthias (1994). “A Syntactic Approach to Type Soundness” (英語). Information and Computation 115 (1): 38–94. doi:10.1006/inco.1994.1093 2026年1月21日閲覧。.
  42. ↑ Macrakis, Stavros (April 1982). “Safety and power” (英語). ACM SIGSOFT Software Engineering Notes 7 (2): 25–26. doi:10.1145/1005937.1005941.
  43. ↑ “Extra, Extra - Read All About It: Nearly All Binary Searches and Mergesorts are Broken”. Google Research (2006年6月2日). 2026年1月21日閲覧。
  44. ↑ Beuhler, Patrick (2021年7月5日). “When Small Software Bugs Cause Big Problems” (英語). Grio Blog. 2023年7月16日閲覧。
  45. ↑ Gleick, James (1996年12月1日). “A Bug and A Crash”. The New York Times. 2019年1月17日閲覧.
  46. ↑ “Ariane 501 - Presentation of Inquiry Board report”. European Space Agency. 2026年1月21日閲覧。
  47. ↑ Lenclud, Christophe (2017年4月21日). “Debugging IBM MACRO Assembler Version 1.00”. 2026年1月21日閲覧。
  48. ↑ Mouawad, Jad (2015年4月30日). “F.A.A. Orders Fix for Possible Power Loss in Boeing 787”. The New York Times. 2026年1月21日閲覧.
  49. ↑ “US-2015-09-07: Electrical Power – Deactivation”. Airworthiness Directives. European Aviation Safety Agency (2015年5月4日). 2026年1月21日閲覧。
  50. ↑ Kravets, David (2017年6月15日). “Sorry ma'am you didn't win $43M – there was a slot machine 'malfunction'”. Ars Technica. 2026年1月21日閲覧。
  51. ↑ Pittman, Jamey. “The Pac-Man Dossier”. 2026年1月21日閲覧。
  52. ↑ “Far Lands” (英語). Minecraft Wiki. 2023年9月24日閲覧。
「https://ja.wikipedia.org/w/index.php?title=整数オーバーフロー&oldid=110972332」から取得