生成的C代码（来自Pro * 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 precompiler option，您还会在#line指令中看到原始LINES文件的完整路径。 （这允许C编译器根据原始源文件中的行号报告错误，这比尝试从生成的源中的行中找出它更容易。）

我怀疑，但我不完全确定，它已包含在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哈希值是基于INAME生成的 参数传递给Pro * C / C ++命令。这可能会导致问题 在存储具有相同名称的文件的应用程序中 包含不同功能和构建的不同目录 脚本被发送到物理目录以预编译程序。 因此，不需要将makefile放在更高的级别 并使用其路径名预编译文件。