抑制宏的比较始终为 true 警告?
我想知道当比较的相反目标是宏时是否有一种简单/明智的方法可以让 gcc 停止抛出此错误。是的,我认识到,使用这个宏的特定定义,比较总是正确的,但它显然不能扩展到一般情况:
#define ROMBOT 0x00000000
#define ROMTOP 0x00002000
...
if (addr >= ROMBOT && addr < ROMTOP) {
simulator.c:517:2: error: comparison of unsigned expression >= 0 is always true
一种解决方案将达到以下效果:
#if ROMBOT == 0
if (addr < ROMTOP) {
#else
if (addr >= ROMBOT && addr < ROMTOP) {
#endif
但是看起来真的很笨拙/维护成本很高。
或相关的:
#define CHECK_ROM_BOT(_addr) (... etc)
但这很快就会升级为许多丑陋/不必要的宏。
有人有什么想法吗?
I'm wondering if there's a simple / sane way to get gcc to stop throwing this error when the opposing target of the comparison is a macro. Yes, I recognize that with this particular definition of the macro, the comparison is always true, but it obviously doesn't extend to the general case:
#define ROMBOT 0x00000000
#define ROMTOP 0x00002000
...
if (addr >= ROMBOT && addr < ROMTOP) {
simulator.c:517:2: error: comparison of unsigned expression >= 0 is always true
One solution would be something to the effect of:
#if ROMBOT == 0
if (addr < ROMTOP) {
#else
if (addr >= ROMBOT && addr < ROMTOP) {
#endif
But that seems really ungainly / high-maintenance.
Or the related:
#define CHECK_ROM_BOT(_addr) (... etc)
But that quickly escalates into a lot of ugly / unnecessary macros.
Anyone have any ideas?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
一种可能的方法是使用两个可能会更改的变量,因此:
如果这些变量在当前源文件之外可见,则它们可能会在编译器无法通过编译此文件看到的情况下发生更改,因此它无法合法地发出警告比较。
警告(因为我没有使用
-Werror
进行编译)会针对您的原始代码出现,而不是针对建议的替换代码出现。您需要考虑变量的类型,但 uintptr_t 可能是合理的。One possible way is to use two variables which could, perhaps, be changed, thus:
If these variables are visible outside the current source file, they could change under circumstances that the compiler cannot see from compiling this file, so it cannot legitimately warn about the comparison.
The warning (since I didn't compile with
-Werror
) appears for your original code and not for the suggested replacement code. You'll need to think about the types of the variables, butuintptr_t
is probably reasonable.其他人想到的另一个选择是在与 0 的比较中将 ROMBOT 强制转换为 double。这可能会生成额外的机器指令,具体取决于编译器。转换值可能不准确,但根据 C11,6.3.1.4 第 2 项,它将具有正确的符号,这就是您所关心的。
Another option that someone else thought up is to cast ROMBOT to double in the comparison with 0. This may generate extra machine instructions depending on the compiler. The cast value may not be exact, but according to C11, 6.3.1.4 item 2, it will have the correct sign, which is all you care about.