True Recordのアドレッシング問題

FB^3で登場したTrue Recordにはアドレッシングに問題があります。

例を用いて示します。

下記は”vers”リソースを読むために、リソースのデータ構造をレコードで記述し、リソースのデータを読もうとしています。

Sample 1　 うまくいかない例

　Sample 1のFN GetCopyRight$の返り値は、残念ながら正しくありません。

関数中にPRINT OFFSETOF(versionCopyRight in versionStructure)でversionCopyRightのオフセット値を表示させると良く分かります。期待されるオフセット値は11ですが、実際には12が表示されます。原因は上記赤丸で囲った部分DIM 4 versionShortVersion$で5バイト確保されるところが、6バイト確保されているためです。BYTE宣言以外は偶数アドレッシング化されるようです。

これがFBのバグなのか、高速化のため意図的にされているのか分かりませんが、注意が必要です。

下記に正しく動く、一例を示します。

Sample 2　　 正しく実行される場合

versionShortVersion`　〜　versionShortLL` というようにBYTE宣言で無理矢理BYTE数を合わせます。これでversionCopyRight$が正しく読込む事ができます。なおversionShortVersionで始まる文字列ですが、宣言文ではversionShortVersion`というようにBYTE宣言をしていますが、関数中に示すように
ver$ = verResHndl..versionShortVersion$
として文字変数のように扱う事もできます。この例では便利ですが、ある意味気をつけなければならず、参照変数型(`, %, &, $など)は必ず付け意図したものが得られるようにしなければなりません。