1. 導入：なぜこの問題が「実務」で恐れられるのか
実務でレガシーなFortranコードを保守していると、コンパイルは通るのに実行時に突如としてセグメンテーションフォールト（Segmentation Fault）が発生する現象に遭遇することがあります。その原因の多くが「サブルーチンの引数として定数を渡し、その内部で値を書き換えようとする」という実装ミスです。現代のプログラムではコンパイラが警告を出してくれますが、古いコードベースではこの「禁じ手」が潜在的なバグとして残っており、メモリ保護違反の温床となっています。本稿では、なぜこれがシステムをクラッシュさせるのか、その仕組みと回避策を解説します。
2. 基礎知識：リテラル定数とメモリ領域
Fortranにおいて、`CALL SUB(1.0)` と記述した際、`1.0` は「リテラル定数」として扱われます。多くのOSやコンパイラ環境では、これらのリテラル定数はメモリ上の「読み取り専用（Read-Only）」領域に配置されます。
一方、サブルーチン側で `SUBROUTINE SUB(A)` と定義し、引数 `A` に対して `A = 2.0` と代入を行うと、プログラムはメモリ上のそのアドレスに対して書き込みを試みます。読み取り専用領域に対して書き込みを行おうとするため、CPUが例外を発生させ、結果としてOSがプロセスを強制終了（アベンド）させます。これが「引数の書き換えによるアベンド」の正体です。
3. 実装/解決策：INTENT属性による防御
この問題を未然に防ぐための最も強力な解決策は、Fortran 90以降で導入された `INTENT` 属性を明示することです。`INTENT(IN)` を指定すれば、引数を変更しようとした時点でコンパイラがエラーを吐き出してくれます。もし値を変更する必要がある場合は、必ず呼び出し側のコードで変数として定義し、その変数を渡すように設計を見直してください。
4. サンプルプログラム：危険なコードと安全な実装
以下に、アベンドが発生する例と、それを回避する安全な実装例を示します。
SUBROUTINE DANGEROUS_SUB(A)
REAL, INTENT(INOUT) :: A
! リテラルを直接渡すと、ここでセグメンテーションフォールトが発生する可能性がある
A = 2.0
END SUBROUTINE
PROGRAM MAIN
REAL :: VAR
VAR = 1.0
! 変数として定義してから渡すことで、メモリの書き込み許可がある領域を操作する
CALL SAFE_SUB(VAR)
PRINT , “変更後の値:”, VAR
END PROGRAM
SUBROUTINE SAFE_SUB(A)
! INTENT(INOUT)を明示することで、誤った定数渡しをコンパイル時に検知できる
REAL, INTENT(INOUT) :: A
A = 2.0
END SUBROUTINE
5. 応用・注意点：レガシー保守の現場で
古いコードを扱う際、全ての引数に `INTENT` を付与するのは膨大な工数がかかるかもしれません。しかし、デバッグが困難なランタイムエラーを減らすためには、以下の順で対策することをお勧めします。
1. コンパイラオプションの活用:
Intel Fortranであれば `-check arg_temp_created` や `-warn all` などのオプションを付与し、引数の不整合を可視化してください。
2. インターフェースブロックの利用:
古いサブルーチンであっても、`INTERFACE` ブロックを作成して引数の型と `INTENT` を明示的に宣言することで、コンパイラによるチェックを強制できます。
3. 「定数渡し」の徹底排除:
「引数を変更するサブルーチンには定数リテラルを渡さない」というコーディング規約をチーム内で共有し、コードレビューのチェックリストに加えることが、最も確実な再発防止策となります。
コメント