導入
PL/I等のレガシーシステムにおいて、文字列の特定範囲に対するポインタを直接取得するテクニック（ADDR(SUBSTR(…))）は、メモリコピーを回避し、高速なデータ処理を実現するための常套手段です。しかし、この手法はメモリの物理的配置やデータ型に深く依存しており、安易な実装は予期せぬメモリアクセス違反や誤動作を招きます。本稿では、この「ポインタ・ハック」の仕組みと、現代的なシステムへの移行時に考慮すべき設計上の注意点を解説します。
基礎知識
ADDR関数は、指定した変数のメモリ上の先頭アドレスを返すビルトイン関数です。通常、変数は静的にメモリ配置が決定されますが、SUBSTR関数による部分参照を引数に取った場合、コンパイラは「その部分文字列の開始位置」を計算し、一時的な記述子（Descriptor）を生成します。
ここで重要なのは、VARYING属性やBIT属性の扱いです。VARYING変数は先頭に長さ情報（Length Prefix）を持つため、単純なオフセット計算では実際のデータ領域を指さない場合があります。また、BIT属性はビット単位で詰め込まれるため、バイト境界を跨ぐポインタ演算がハードウェアレベルで制限される環境も存在します。
実装/解決策
この手法を用いる際は、対象となる変数が「アライメント（整列）条件を満たしているか」を厳密に定義する必要があります。特に、構造体の一部をサブストリングとして扱う場合は、コンパイラによるパディング（埋め込み）を意識し、DEFINED属性を用いたオーバーレイ構造の利用を検討すべきです。直接ポインタを渡すのではなく、ベースとなるポインタにオフセットを加算する手法が、最も安定した実装となります。
サンプルプログラム
以下は、安全に部分文字列のアドレスを操作するための実装例です。
/ PL/Iによるポインタ演算のサンプル /
DCL LONG_STR CHAR(100) BASED(P_STR);
DCL P_STR POINTER;
DCL P_SUB POINTER;
DCL OFFSET FIXED BIN(31) INIT(10); / 開始位置 /
/ 直接ADDR(SUBSTR())を使わず、ベースポインタに加算する手法 /
/ これにより、コンパイラによる不要な一時コピーを抑制する /
P_SUB = P_STR + (OFFSET – 1);
/
注意: 上記手法は変数が非VARYINGかつ固定長であることが前提。
VARYING変数の場合は、先頭の長さ情報を考慮して +2 バイト等の補正が必要。
/
応用・注意点
現代の言語（JavaやC#、Goなど）へ移行する際、PL/Iの「ポインタによる参照」は、そのままでは再現できません。多くのモダン言語ではSUBSTRを実行すると、メモリの新規確保（コピー）が発生します。
移行先で同様のパフォーマンスを維持したい場合、以下の点に注意してください。
1. スライス/ビューの利用: 言語が提供する「スライス」機能（GoのSliceやRustのStringView等）を利用し、メモリをコピーせずに既存領域を参照する設計に変更すること。
2. アライメントの再確認: 移行先が64bit環境であれば、ポインタのアライメント（8バイト境界）を意識する必要があります。古いコードで許容されていた奇数アドレスへのアクセスが、プロセッサの例外を引き起こす可能性があるためです。
3. コンパイラ最適化の副作用: ADDR関数を多用すると、コンパイラによる最適化（レジスタへのキャッシュ等）が阻害される場合があります。パフォーマンス重視であれば、ポインタを多用するのではなく、構造体そのものを適切に定義し直すリファクタリングを推奨します。
コメント