absolute-path - （Pro * Cから）生成されたCコードには絶対パスが含まれています

Question

私は何年も前にPro*Cから生成されたCコードを監査していますが、これを見つけました：

static const struct sqlcxp sqlfpn =
{
    33,
    "d:¥¥VS¥¥Projects¥¥SOMEDIR¥¥somefile.pc"
};

コード内の絶対パスは、品質規則によって禁止されています。
OracleのPro*C→Cコンバーターは本当にそんなに悪いことをしているのでしょうか、それとも私は何かを逃したのでしょうか？

Answer 1

これは文書化されていないsqlctx()関数によって使用されており、Pro*Cがこの構造を生成するのを止めることはできないと思います。それが本質的に悪いことかどうかはわかりません。生成されたコードに表示され、Oracleによって内部的に使用されるものです。

プリコンパイラオプションをオンにしている場合は.pc、ディレクティブに元のファイルのフルパスも表示されます。（これにより、Cコンパイラは元のソースファイルの行番号に対してエラーを報告できます。これは、生成されたソースの行からエラーを把握するよりもはるかに便利です）。#lineLINES

に含まれているのではないかと思いますが、完全にはわかりません。そのsqlctx()ため、値は内部エラーにも使用でき、場合によってはデバッグにも使用できます。

コーディング標準の観点からは、ソースにフルパスがあることは、パスが変更された場合にコードに触れる必要があるため、おそらく悪いことと見なされます。ただし、次のビルドで新しいパスが自動的に取得されるため、生成されたコードではかなり意味がないようです。ただし、他の理由（最小限のビルド情報を明らかにするための包括的なセキュリティ要件など）がある場合は、フルパスが最終的なバイナリにも表示されることに注意する必要があります。（Linuxでは、stringsフルパスを示しています。Windowsに相当するものについてはわかりませんが、どこかにあると思います）。生成されたコードを監査している場合、それは実用的なものというよりはセキュリティのように聞こえます。

iname本当に重要な場合は、ソースディレクトリに移動し、パスを含まないファイル名を指定することで、フルパスを回避できます。

cd d:\VS\Projects\SOMEDIR
proc iname=somefile.pc ...

それ以外の

proc iname=d:\VS\Projects\SOMEDIR\somefile.pc

Answer 2

実際には理由があります：e10825 p313：

注：sqlctxハッシュ値は、Pro * C /C++コマンドに渡されたINAMEパラメーターに基づいて生成されます。これにより、同じ名前のファイルが異なる関数を含む異なるディレクトリに保存され、ビルドスクリプトが物理ディレクトリに送信されてプログラムをプリコンパイルするアプリケーションで問題が発生する可能性があります。その結果、makefileをより高いレベルに配置し、パス名を使用してファイルをプリコンパイルする必要はありません。