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

Question

Pro * C ages前に、生成されたCコードを監査しています。そして私はこれを見つけました：

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

.

コード内の絶対パスは、私たちの品質規則によって禁止されています。
OracleのPro * C→C Converterは本当に悪いことをやっている、または私は何かが恋しいですか？

Answer 1

これは文書化されていないsqlctx()関数で使用されていますが、この構造を生成するPro * Cを停止できるとは思わない。私は本質的に悪いことであると確信していません、それは生成されたコードに現れるものだけで、Oracleによって内部的に使用されます。

.pc プリコンパイラオプションがオンになっています。 （これにより、Cコンパイラは元のソースファイル内の行番号に対してエラーを報告できます。これは、生成されたソースの行からそれを把握しようとするよりもはるかに便利です）。

私は疑われるが、それは一般的にはsqlctx()に含まれているので、値は内部エラーにも使用でき、場合によってはデバッグのために使用することができます。

コーディング標準の観点から見た、あなたの情報源のフルパスを持つことはおそらく、パスが変更された場合にコードに触れる必要があるため、悪いことと考えられています。しかし、それは新しいパスが次のビルドで自動的にピックアップされるため、生成されたコードではむしろ起動しているようです。ただし、他の理由がある場合 - 最小限のビルド情報を明らかにするための毛布のセキュリティ要件がある場合は、フルパスも最終的なバイナリに表示されることに注意する必要があります。 （Linuxでは、stringsはフルパスを表示します。Windowsの同等のアイデアはありませんが、どこかにあると想像します。生成されたコードを監査している場合は、実用的なものではなくセキュリティのように聞こえます。

それが本当に問題ない場合は、ソースディレクトリに移動し、inameにパス名を指定してファイル名を指定するだけで、

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

. の代わりにp>

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

.

Answer 2

実際には理由があります。 E10825 P313：

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