【问题标题】:Is there no gcc warning when a literal declared as long is assigned to an int in c?将声明为 long 的文字分配给 c 中的 int 时是否没有 gcc 警告?
【发布时间】:2022-01-08 03:28:13
【问题描述】:

我可以编译并运行一个程序,该程序将一个 long int 字面量(尽管它适合 int)分配给一个 int 变量。

$ cat assign-long-to-int.c
#include <stdio.h>

int main(void){
  int i = 1234L;        //assign long to an int
  printf("i: %d\n", i);
  return 0;
}
$ gcc assign-long-to-int.c -o assign-long-to-int
$ ./assign-long-to-int 
i: 1234

我知道 1234 适合 int 但仍希望能够启用警告。我已经浏览了所有gcc options,但找不到合适的。

是否可以针对这种情况生成警告?从这里的讨论和 gcc 选项来看,简短的回答是否定的。这是不可能的。

这样的警告有什么意义吗? 在我发布的简单示例中,很明显 1234L 被分配给一个 int 变量,并且它将适合。但是,如果声明和赋值被多行代码分开怎么办?编写 1234L 的程序员表示他们期望这个字面整数被分配给一个 long。不然加L有什么意义?

在某些情况下,附加 L 确实会产生影响。例如

$ cat sizeof-test.c 
#include <stdio.h>
void main(void){
  printf("%ld\n", sizeof(1234));
  printf("%ld\n", sizeof(1234L));
}
$ ./sizeof-test 
4
8

虽然编译器必须知道 1234L 可以放入 4 字节的 int 中,但它会将其放入 8 字节的长度中。

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-17ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)

【问题讨论】:

  • 编译器认为它适合。如果增加数字,您将收到预期的警告:godbolt.org/z/PEscnjdvG
  • 不知道 gcc 但 MS VC 在它不适合时会发出警告,但在适合时不会发出警告。也许 gcc 具有更高的警告级别,例如 -Wall
  • @WeatherVane: -Wall 甚至 -Wextra 不会导致此代码发出警告。
  • 类似的 MSVC 会为 float f = 1.2; 发出警告,但不会为 float f = 1.25; 或 float f = 1.2f; 发出警告。
  • 简短的回答是否定的,这是不可能的。在这里很难选择任何一个答案作为“正确答案”,所以我将所有答案都标记为有用。

标签: c gcc gcc-warning gcc9


【解决方案1】:

编译器应该检查值范围,而不是整数常量的类型。否则,每当我们初始化一个小整数类型时,我们最终都会有很多抱怨,因为没有小于int 的小整数常量。

short i = 32768; 确实会产生一个警告,例如使用 clang -Wconstant-conversion 但不会使用 gcc。有-Wconversion,但在任一编译器上都容易出现误报。

如果您想防止各种整数类型之间的隐式转换,您可能应该改用静态分析器。

【讨论】:

    【解决方案2】:

    在常量的情况下,编译器可以看到有问题的值适合分配给的类型,所以警告真的没有意义。如果常量超出范围,即5000000000L,那么编译器会看到并生成警告。

    然而,编译器可以做的事情是当一个不是编译类型常量的整数类型被分配给一个较低的类型时发出警告:

    long y = 1;
    int x = y;
    

    如果您添加-Wconversion 标志(不包含在-Wall 或-Wextra 中),您将收到以下警告:

    x1.c:6:5: warning: conversion to ‘int’ from ‘long int’ may alter its value [-Wconversion]
         int x = y;
    

    【讨论】:

    • 重点是什么?我在我的问题中添加了一些内容。
    【解决方案3】:

    编译器将自动在大多数原始整数类型之间进行转换。当您从较大的类型转换为较小的类型时,我很确定这是 C 语言的一个特性,即数字将被截断。

    例如,以下代码将打印“0xef”:

    #include <stdio.h>
    #include <stdint.h>
    int main() {
      uint32_t x = 0xdeadbeef;
      uint8_t y = x;
      printf("0x%x\n", y);
      return 0;
    }
    

    为了具体解决您的问题,我认为不会对这种行为发出警告,因为这种转换在技术上是 C 语言的定义特性。

    【讨论】:

    • 这更像是一个语言错误而不是一个功能。为什么short i = 32768; 应该导致i 获得-32768 的值对任何人来说可能都不是很明显。或者为什么int32_t i = 0x7eadbeef; 具有明确定义的行为,但int32_t i = 0xdeadbeef; 导致i 变为负数。这是 C 语言中最糟糕的部分之一。
    • @Lundin 这些示例并不是 C 语言的不足...期望程序员理解诸如 2 的补码表示或算术/逻辑移位之类的概念可能不适合“初学者”,但这种行为完全符合 C 语言“信任程序员”的理念。话虽如此,我确实认为这是 GCC 的一个合理特性,即在从文字分配给整数时捕获符号翻转。
    • 你在这个答案中说应该截断更大的数字。现在你说它们不应该被截断,而是按照 2 的补码溢出 - 一种标准不保证的签名格式。与算术/逻辑移位类似,不确定您为什么提出它,但标准也不能保证。然而,C 标准确实保证 0x7eadbeef 的类型为 signed int,但 0xdeadbeef 的类型为 unsigned int。完全有道理吗? -->
    • 那么C到底应该信任程序员做什么呢?相信程序员会犯错误,因为他们认为 C 类型系统是一致且合理的?相信程序员会编写 C 标准未涵盖的未指定的不可移植代码吗?不,C 处理整数类型的方式总体上是完全错误的,这没有错。
    • 谈到定义不明确的损坏功能,使用%x 打印uint8_t 也是未定义的行为。它被默认参数提升隐式转换为int(顺便说一句,这有什么意义?)但%x 需要unsigned int。你的代码在这里要做的事情根本不是由 C 语言定义的。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2010-12-16
    • 1970-01-01
    • 2019-08-06
    • 1970-01-01
    • 1970-01-01
    • 2016-02-09
    • 2016-11-25
    相关资源
    最近更新 更多