導入
数値計算の現場で、数十年前から稼働しているレガシーなFortranコードに出会うことは珍しくありません。その際、最も頭を悩ませるバグの一つが「COMMONブロックの定義不一致」です。異なるプログラムユニット間で、共通領域（COMMONブロック）の型や順序が定義通りに一致していない場合、コンパイラはエラーを出さずに、メモリ上で意図しない「暗黙の型変換」や「データ破壊」を引き起こします。本記事では、この挙動がなぜ危険なのか、そしてどう回避すべきかを解説します。
基礎知識
COMMONブロックとは、プログラム内の複数のルーチンで共有するメモリ領域のことです。Fortranの仕様上、COMMONブロックは「名前」で識別されますが、その中身のデータ構造は、各ルーチンで定義された「宣言の順番」に依存します。
もし、ルーチンAで「REAL8（8バイト）」を1つ定義し、ルーチンBで「REAL4（4バイト）」を2つ定義した場合、メモリ上では同じ16バイト（または8バイト）の領域を指していても、参照する際の「解釈」が異なります。これが不当なキャストとなり、数値の精度低下や、全く異なる値への化けを引き起こす原因となります。
実装/解決策
この問題を防ぐための鉄則は「共通定義ファイル（Includeファイル）」の利用です。COMMONブロックの宣言を直接各ファイルに書くのではなく、1つのヘッダーファイルに集約し、それを `INCLUDE` 文で読み込むことで、定義のズレを物理的に発生させない環境を構築します。
サンプルプログラム
以下のコードは、定義の不一致がどのように数値を破壊するかを再現する例です。
! --- メインプログラム --- PROGRAM MAIN REAL8 :: A, B COMMON /BLK/ A, B A = 1.0D0 B = 2.0D0 CALL SUB() ! 期待値とは異なる結果が返ってくる可能性がある END PROGRAM MAIN ! --- サブルーチン --- SUBROUTINE SUB() REAL4 :: C(2) COMMON /BLK/ C ! 本来はREAL8(8バイト)が来るべき場所に、REAL4(4バイト)を2つ配置 ! これにより、呼び出し側のデータが意図せず上書き・参照される PRINT , "受信データ1:", C(1) PRINT , "受信データ2:", C(2) C(1) = 9.9E0 ! メモリ上のAを破壊する可能性がある END SUBROUTINE SUB
応用・注意点
現場でのデバッグにおいて、このバグは非常に厄介です。なぜなら、データが汚染されている箇所と、その原因（不一致の宣言）が別のファイルに存在することが多いためです。
1. 静的解析ツールの活用: プロジェクト全体をスキャンし、COMMONブロックの定義を比較できるツールを利用してください。
2. Moduleへの移行: 可能であれば、古いCOMMONブロックを廃止し、Fortran 90以降の `MODULE` 機能へ移行することを強く推奨します。MODULEを使えば、コンパイル時に型の不一致を確実にチェックできるため、このようなレガシーなバグを根絶できます。
3. アライメントへの配慮: コンパイラによっては、データのアライメント（境界調整）により、宣言順序以外にもメモリ配置が変わることがあります。`SAVE` 属性の付与や、構造体（TYPE）での定義への置き換えを検討してください。
レガシーコードの保守においては「動いているから触らない」ではなく、「いつ壊れてもおかしくない箇所を特定する」姿勢が、エンジニアとしての信頼を守ります。
コメント