在源代码中部分禁用 gcc 中的迂腐警告答案

【问题标题】：Partially disable pedantic warnings in gcc within source在源代码中部分禁用 gcc 中的迂腐警告
【发布时间】：2013-01-13 14:09:36
【问题描述】：

我试图让gcc 闭嘴我对二进制常量的使用。它们使代码更具可读性，但阻止我使用-pedantic，否则我会遵守。我想要一个像-fnobinaryconstwarn 或类似的开关（我认为在仔细阅读手册页一段时间后不存在）或使用

#pragma GCC diagnostic ignored "-pedantic"

选择性地在短时间内禁用迂腐警告，如下所述： Selectively disable GCC warnings for only part of a translation unit? 不幸的是，这似乎不起作用。我有哪些选择？

对于clang

#pragma GCC diagnostic ignored "-Wpedantic"

有效，而上面的行无效，但它会为gcc 生成错误。

【问题讨论】：

你能举一个“使用二进制常量”的例子吗？
与这些类似：unsigned int piece = 0b10010101; 该功能是在 gcc-4.3.0 中引入的。我实际上认为问题更严重，因为如果该特定警告没有标志，则应该可以以某种方式关闭 -pedantic 引入的警告。
gcc 应该在这些东西上更加模块化，对其所有功能都有明确的警告标志，然后-Wall，-pedantic 任何标志应该清楚地列出它们组成的所有原始标志。但这可能是一厢情愿。
GCC 4.8 将支持-Wpedantic，所以#pragma 可以工作
@JensGustedt，这就是它的工作原理。打印警告时，它会告诉您是哪个-Wxxx 选项引起的。 -pedantic 是一个单一功能（诊断非标准扩展），因此只有一个标志。

标签： c gcc suppress-warnings

【解决方案1】：

来自 gcc 手册：http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Alternate-Keywords.html#Alternate-Keywords

-pedantic 和其他选项会导致许多 GNU C 扩展出现警告。您可以通过在表达式前写 __extension__ 来防止在一个表达式中出现此类警告。 __extension__ 除此之外没有任何影响。

我刚刚使用 gcc-4.8.2 使用 -Wall -Wextra -Wpedantic 编译了以下块，并且没有打印任何警告：

static uint8_t shbl[2][9] = {
{ __extension__ 0b11111111,
  __extension__ 0b11111110,
  __extension__ 0b11111100,
  __extension__ 0b11111000,
  __extension__ 0b11110000,
  __extension__ 0b11100000,
  __extension__ 0b11000000,
  __extension__ 0b10000000,
  __extension__ 0b00000000 },
// BLOCK_RIGHT
{ __extension__ 0b11111111,
  __extension__ 0b01111111,
  __extension__ 0b00111111,
  __extension__ 0b00011111,
  __extension__ 0b00001111,
  __extension__ 0b00000111,
  __extension__ 0b00000011,
  __extension__ 0b00000001,
  __extension__ 0b00000000 }
};

（当然这很难看，我会将其更改为预编译器宏。但对于测试来说它是可以接受的。）

【讨论】：

【解决方案2】：

也许，您可以使用一个宏，它可以以可移植的方式完成您想要实现的目标。这是一个简短的例子：

#include <stdio.h>

#define BINARY(N) strtol(#N, 0, 2)

int main()
{
    unsigned int piece = BINARY(10010101);
    printf("%u\n", piece);

    return 0;
}

理论上，gcc 应该能够优化对 strtol 的调用，并且不会失去可读性。

编辑：到目前为止，gcc 似乎没有优化 strtol 调用。但是，您的性能损失应该可以忽略不计。

干杯！

【讨论】：

这似乎是一个非常特殊的情况，gcc 4.7.2 没有优化-O3 中的这段代码，仍然调用strtol。
@lbonn 哦。我真的没想到会因为不断的争论。
这应该是可能的，但显然没有人足够关心来编写这个优化。也许这个用例被认为太罕见了。