GCC – 在为char分配int时不应该发出警告吗?

我最近在笔记本电脑上设置了MinGW + MSYS环境,以检查Netbeans C / C ++支持的情况。 一切似乎都运行良好,但是,在我的测试中,我注意到GCC和Microsoft的cl.exe编译器之间存在差异。

这是一个示例程序:

#include  #include  #include  int main(void) { int i_max = INT_MAX; char c_max = CHAR_MAX, c; c = i_max; printf("i_max: %d, c_max: %d, c: %d\n", i_max, c_max, c); return EXIT_SUCCESS; } 

输出是:

 i_max: 2147483647, c_max: 127, c: -1 

正如您在上面的代码中看到的,我将一个int分配给一个char。 这不应该产生可能发生数据丢失的警告吗? 微软的编译器(我配置得非常严格)会发出警告而GCC没有。

以下是我使用的GCC选项:

 -g -Werror -ansi -pedantic -Wall -Wextra 

我错过了一些GCC选项,使编译时检查更严格吗?

您正在寻找

 -Wconversion 

您必须向gcc开发人员询问为什么某些警告未包含在-Wall-Wextra的具体原因。

无论如何,这些是我使用的标志:

 -Wall -Wextra -Wmissing-prototypes -Wmissing-declarations -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wredundant-decls -Wnested-externs -Winline -Wno-long-long -Wconversion -Wstrict-prototypes 

正如其他人所指出的那样, -Wconversion的行为随着版本4.3 -Wconversion改变 – 关于强制进行类型转换的原型的旧警告现在可用作-Wtraditional-conversion

我也没有得到-Wconversion的警告/错误。 但是,如果您使用splint等方法传递,则会收到三个警告:

 file.c: (in function main) file.c:9:5: Assignment of int to char: c = i_max To make char and int types equivalent, use +charint. file.c:10:52: Format argument 2 to printf (%d) expects int gets char: c_max file.c:10:32: Corresponding format code file.c:10:59: Format argument 3 to printf (%d) expects int gets char: c file.c:10:39: Corresponding format code Finished checking --- 3 code warnings 

如果您认真捕捉所有错误,则应使用多个工具。

你的问题有点细微差别,从措辞的方式来看,这对我来说并不是很明显。

如果你认为GCC(特别是GCC)应该在这里发出警告,那么一些编译器选项可能会有所帮助(参见其他回复)。

如果你认为任何编译器都应该在这里发出警告(我似乎在你的问题中读到这种情绪),那么……好吧,“警告”绝不是强制性的,甚至不是事实统一的。 这里没有“应该”。 在没有显式强制转换的情况下将较大类型的整数值分配给较小的类型在C中是完全合法的。转换时溢出,产生实现定义的行为(它甚至不是UB :))

-Wall 并不意味着-Wall ,-Wextra已经因为过于迂腐而受到抨击。

正如Christoph所说,你正在寻找-Wconversion。 真正深入了解-Wall和-Wextra实际打开的内容,只需在make文件中指定所需的-W标志,尤其是将警告视为错误时。

在C中,为char分配int是合法的。

由于它是合法的(但可能是狡猾的),不同的编译器供应商在遇到此代码时会做不同的事情。

我猜MS只是在愚蠢,而海湾合作委员会的人已经决定它甚至不值得警告。

我认为它属于“常用算术转换”(6.3.1.8)或“整数提升规则”(5.1.2.3(?)),但我找不到具体的文字说明你所看到的行为是预期的。