Question

- 预条件：

我知道它有很多方法可以忽略这个警告，但是我确实需要修复它但不只是为编译器添加一些标志来忽略它，因为我可以在我的本地修改makefile CFLAG，但是由于公司质量控制原因，编译/构建策略无法更改。这个问题我只想讨论谁以一种好的方式修复它但不要忽视它们，非常感谢！

与此同时，不仅仅会引用一些变量，而且还会发出警告：

function 'xxx' was declared but never referenced

头文件中的类似问题，它有一些静态函数，只能在一个c文件中使用，但许多其他c文件包含这个头文件。

此外，此代码在专用目标上运行，该目标具有关键内存消耗，这意味着我需要处理ROM和RAM中的每个位。

-------问题显示在下面-----------

我目前正在构建一些代码，这些代码由供应商提供并且包含大量警告，因为我希望免费构建警告，因此，我为-Werror和{{1}添加了gcc } --diag_error=[error_ref_number]。

在上面的makefile修改之后，我目前遇到的最多警告是

armcc

由以下编码风格引起：

在variable 'xxx' was declared but never referenced中，它定义了一些变量（例如，但供应商的代码完全相同）：

veryBIG.h

但是，许多c文件都包含这个BIG头文件，但只有这些c文件中的一个使用上述变量之一，就像static const int a = 10; static const int b = 20; static const int c = 30; ... static const int z = xx;将使用变量a.c，a使用变量b.c等等。

我有两种方法可以解决：

将这些变量移入专用的c文件中，这意味着头文件变得无用
单独的头文件，意味着我创建b，a.h，...，b.h，每个专用c文件只包含上述头文件之一

然而，这两种方式都限制了我的工作，

方式1 ：

我不确定供应商的进一步更新是否会将此头文件更改为具有更新值或具有更新值，因为供应商不想修复此编译警告，这意味着如果我按照方式1，我将手动更新这些变量如果它已被供应商更改（仅在头文件中，我必须将它们同步到c文件），这种方式使我的进一步合并工作变得复杂

方式2 ：

它还使我的进一步合并工作变得不容易，因为我不使用供应商的方式，我还需要修改系统makefile以使这些头文件适应z.h PATH，如果它们不在同一文件夹中（PATH已经为INC定义）

如果有任何想法可以解决这个问题？

更新

我可以暂时使用veryBIG.h Wno-xxx并删除标记gcc中的一些[error_ref_number]（例如--diag_error，并删除CFLAG += --diag_error=550,223,188,177,....,在177中传递此警告并使我的编译继续并首先修复其他警告，但我确实需要修复所有警告。

Answer 1

AFAIK，已声明警告变量'xxx'但从未引用对现代设备完全无风险。唯一的威胁是，当程序加载时，变量可能占用一点内存空间，即使是最小的现代机器也不会因为少量的内存浪费而遭受OOM。 BTW现代编译器将为您优化，为什么他们不会，因为编译器已经警告过你。你可以忽略警告。

如果您发现警告令人讨厌，只需在编译期间添加-Wno-unused-variable标志。

编辑：正如亚历克斯在评论中所说，我错了。但你可以看到，即使是我提到的那么小的风险也是假的。所以放松一下。

我所知道的几乎所有开源项目都会有未引用的变量，我没有看到任何人做出太多努力来消除它。

再次编辑：好吧，我发现您需要免费提供绝对警告。好吧，我能想到的唯一解决方案就是使用#define宏来减少工作时间。

在头文件中创建#ifdef /＃else /＃endif块，并在C文件中添加#defines。但是你仍然需要花费大量时间来确定依赖关系。

您的头文件看起来像这样：

#ifdef __A__
static const int var_used_in_A;
#endif
#ifdef __B__
static const int var_used_in_B;
#endif
#ifdef __EXTRA__
static const int var_used_in_both;
#endif

并且你的A.c文件看起来像这样：

#define __A__
#define __EXTRA__
#include "BigHeader.h"
.....

glext.h如何为OpenGL工作。这比打破许多较小的头文件要好，因为您可以通过MACROS清楚地看到依赖关系，而许多文件将要求您提供良好的文档。而宏比文件更灵活。

如果您可以与您提到的供应商协商，以便始终告诉您他们所做的不同，那就太好了，您可以将它们添加到正确的位置。如果你不能只保留原始的VeryBIG.h的历史记录并使用diff工具来检查新的变化。

Answer 2

如果您关心内存使用情况到每个位都重要的地方，那么您可能应将该头文件拆分成许多小块，因为没有实际保证编译器不会在每个static文件中反复发出.c个变量和函数中的每一个，即使只使用了其中的一小部分。（as-if规则表示编译器可能删除所有未使用的静态，但没有任何说法必须。）

在你的鞋子里，我可能会写一些自动分解的脚本;然后，当发布新版本时，我不必再重新做一遍。

解决“变量'xxx'的最佳方法已被宣布，但从未被引用过”

2 个答案: