我正在审核生成的 C 代码 前*C 很久以前,我发现了这个:

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

我们的质量规则禁止代码中的绝对路径。
Oracle 的 Pro*C→C 转换器真的做了这么糟糕的事情,还是我错过了什么?

有帮助吗?

解决方案

这是由无证人员使用的 sqlctx() 函数,我认为你不能阻止 Pro*C 生成这个结构。我不确定这本质上是一件坏事,它只是出现在生成的代码中并由 Oracle 内部使用的东西。

您还将看到原始的完整路径 .pc 文件输入 #line 指令,如果您有 LINES 预编译选项 打开。(这允许 C 编译器根据原始源文件中的行号报告错误,这比尝试从生成的源文件中的行中找出错误要方便得多)。

我怀疑,但我不完全确定,它包含在 sqlctx() 因此该值也可用于内部错误,并且可能用于调试。

从编码标准的角度来看,在源代码中拥有完整路径可能被认为是一件坏事,因为如果路径发生变化,您就必须修改代码;但这在生成的代码中似乎毫无意义,因为新路径将在下一次构建时自动选择。但是,如果还有其他原因(可能需要透露最少的构建信息的全面安全要求),那么您应该意识到完整路径也将出现在最终的二进制文件中。(在 Linux 中, strings 显示完整路径;不知道 Windows 上有什么类似的东西,但我想它就在那里)。如果您正在审核生成的代码,那么这听起来像是一个安全问题,而不是实际问题。

如果确实重要的话,您可以通过移动到源目录并仅给出文件名而不提供路径来避免完整路径 iname, , IE。

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

代替

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

其他提示

实际上有一个原因: E10825 P313:

注意:SQLCTX哈希值是基于iname生成的 参数传递给Pro * C / C ++命令。这可能导致问题 在存储具有相同名称的文件的应用程序中 包含不同函数和构建的不同目录 脚本将发送到物理目录以将程序预先编译。 结果,无需将makefiles放在更高的级别 和使用他们的路径名的文件预先编译。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top