c - 解决 "variable ' xxx 的最佳方法已声明但从未被引用”

Question

-前置条件:

我知道有很多方法可以忽略此警告，但我确实需要修复它，但不仅仅是添加一些标志让编译器忽略它，因为我可以执行此生成文件 CFLAG在我的本地进行修改，但由于公司质量控制原因无法更改编译/构建策略。这个问题我只是想讨论谁能以好的方式解决它，但不要忽视他们，非常感谢!

同时，不仅一些变量从未被引用，而且它有警告:

function 'xxx' was declared but never referenced

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

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

--------问题如下------------

我目前构建了一些由供应商提供的代码，其中包含很多警告，因为我想要一个无警告的构建，因此，我把 -Werror对于 gcc和 --diag_error=[error_ref_number]对于 armcc .

经过上面的makefile修改，我目前遇到最多的warning是

variable 'xxx' was declared but never referenced

它是由以下编码风格引起的:

在veryBIG.h ，它定义了一些变量，例如(仅作为示例，但供应商的代码具有完全相同的方式):

static const int a = 10;
static const int b = 20;
static const int c = 30;
...
static const int z = xx;

但是，许多c 文件都包含这个大头文件，但这些c 文件中只有一个使用上述变量之一，它像a.c。将使用变量 a , b.c使用变量 b等等。

我有两种修复方法:

1. 把这些变量移到它专用的c文件里，就意味着头文件没用了

2. 单独的头文件，意味着我创建了a.h , b.h , ..., z.h , 并且每个专用的c文件只包含上述头文件之一

但是，这两种方式对我的工作都有局限性，

方式一:

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

方式二:

这也让我进一步的合并工作变得不容易，因为我没有使用供应商方式，我还需要修改系统makefile来将这些头文件适配到INC中。 PATH 如果它们不在同一个文件夹中(PATH 已经为 veryBIG.h 定义)

有什么办法可以克服这个问题吗？

更新

我可以临时用Wno-xxx对于 gcc并删除一些 [error_ref_number]在标志 --diag_error (如 CFLAG += --diag_error=550,223,188,177,...., ，我删除了 177 以在 armcc 中传递此警告)并继续我的编译并首先修复其他警告，但我确实需要修复所有警告。

Answer 1

据我所知，警告已声明变量“xxx”但从未被引用对于现代设备而言完全无风险。唯一的威胁是变量在加载程序时可能会占用一点内存空间，即使是最小的现代机器也不会因为那么少的内存浪​​费而遭受 OOM。顺便说一句，现代编译器会为你优化它，为什么不呢，因为编译器已经警告过你了。您可以忽略该警告。

如果您觉得警告很烦人，只需在编译期间添加 -Wno-unused-variable 标志即可。

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

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

再次编辑: 好吧，我知道你需要绝对警告免费。好吧，我能想到的唯一需要更少工作时间的解决方案是使用#define 宏。

在头文件中创建#ifdef/#else/#endif block ，并在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 工具检查新文件的更改。