absolute-path - 生成的 C 代码（来自 Pro*C）包含绝对路径

Question

我正在审核很久以前从Pro*C生成的 C 代码，我发现了这一点：

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

我们的质量规则禁止使用代码中的绝对路径。
甲骨文的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 置于更高级别并使用其路径名预编译文件。