char - 修复了各种系统上的 CHAR_BIT？

Question

我对 limit.h 中的 CHAR_BIT 感到困惑。我读过一些文章说宏 CHAR_BIT 是为了可移植性。在代码中使用宏而不是像 8 这样的魔数(Magic Number)，这是合理的。但是limits.h来自glibc-headers，它的值固定为8。如果glibc-headers安装在一个字节超过8位(比如16位)的系统上，那么编译时会出错吗？ 'char' 被指定为 8 位还是 16 位？

当我在limits.h中将CHAR_BIT修改为9时，下面的代码仍然打印'8'，这是怎么回事？

#include <stdio.h>
#include <limits.h>

int
main(int argc, char **argv)
{
    printf("%d\n", CHAR_BIT);
    return 0;
}

补充如下:我已经阅读了所有回复，但仍然不清楚。在实践中，#include <limits.h>并使用 CHAR_BIT，我可以遵守。但那是另一回事了。这里我想知道为什么会这样，首先它是glibc/usr/include/limits.h中的固定值“8”，当那些1字节!= 8位的系统安装了glibc时会发生什么；然后我发现值“8”甚至不是代码使用的实际值，所以“8”意味着什么？如果根本没有使用该值，为什么要把“8”放在那里？

谢谢

Answer 1

深入研究系统头文件可能是一种令人畏惧且不愉快的经历。 glibc 头文件很容易在您的头脑中造成很多困惑，因为它们在某些情况下包含其他系统头文件，这些头文件会覆盖迄今为止定义的内容。

以limits.h为例，如果你仔细阅读头文件，你会发现CHAR_BIT的定义仅当您在没有 gcc 的情况下编译代码时才使用，因为这一行:

#define CHAR_BIT 8

位于 if 内条件上面几行:

/* If we are not using GNU CC we have to define all the symbols ourself.
   Otherwise use gcc's definitions (see below).  */
#if !defined __GNUC__ || __GNUC__ < 2

因此，如果您使用 gcc 编译代码(很可能是这种情况)，则 CHAR_BIT 的定义将不会被使用。这就是为什么您更改它并且您的代码仍然打印旧值的原因。在头文件上向下滚动一点，您可以找到您使用 GCC 的情况:

 /* Get the compiler's limits.h, which defines almost all the ISO constants.

    We put this #include_next outside the double inclusion check because
    it should be possible to include this file more than once and still get
    the definitions from gcc's header.  */
#if defined __GNUC__ && !defined _GCC_LIMITS_H_
/* `_GCC_LIMITS_H_' is what GCC's file defines.  */
# include_next <limits.h>

include_next是 GCC 的扩展。您可以在这个问题中了解它的作用:Why would one use #include_next in a project?

简短回答:它将搜索具有您指定名称的下一个头文件(本例中为 limits.h )，并且它将包含 GCC 生成的 limits.h 。 。在我的系统中，它恰好是 /usr/lib/gcc/i486-linux-gnu/4.7/include-fixed/limits.h 。

考虑以下程序:

#include <stdio.h>
#include <limits.h>

int main(void) {
  printf("%d\n", CHAR_BIT);
  return 0;
}

使用此程序，您可以在 gcc -E 的帮助下找到系统的路径。 ，它为包含的每个文件输出一个特殊行(请参阅 http://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html )

因为#include <limits.h>位于该程序的第 2 行，我将其命名为 test.c ，运行gcc -E test.c允许我找到正在包含的真实文件:

# 2 "test.c" 2
# 1 "/usr/lib/gcc/i486-linux-gnu/4.7/include-fixed/limits.h" 1 3 4

您可以在该文件中找到此内容:

/* Number of bits in a `char'.  */
#undef CHAR_BIT
#define CHAR_BIT __CHAR_BIT__

注意 undef指令:需要覆盖任何可能的先前定义。它是在说:“忘记 CHAR_BIT 是什么，这才是真实的”。 __CHAR_BIT__是 gcc 预定义的常量。 GCC的在线文档是这样描述的:

__CHAR_BIT__ Defined to the number of bits used in the representation of the char data type. It exists to make the standard header given numerical limits work correctly. You should not use this macro directly; instead, include the appropriate headers.

您可以通过一个简单的程序读取它的值:

#include <stdio.h>
#include <limits.h>

int main(void) {
  printf("%d\n", __CHAR_BIT__);
  return 0;
}

然后运行gcc -E code.c 。请注意，您不应该直接使用它，正如 gcc 的联机帮助页提到的那样。

显然，如果你改变CHAR_BIT里面的定义/usr/lib/gcc/i486-linux-gnu/4.7/include-fixed/limits.h ，或者您系统中的任何等效路径，您将能够在代码中看到此更改。考虑这个简单的程序:

#include <stdio.h>
#include <limits.h>

int main(void) {
  printf("%d\n", CHAR_BIT);
  return 0;
}

改变CHAR_BIT gcc 中的定义 limits.h (即 /usr/lib/gcc/i486-linux-gnu/4.7/include-fixed/limits.h 中的文件)来自 __CHAR_BIT__ to 9 将使此代码打印 9。同样，您可以在预处理发生后停止编译过程；你可以用gcc -E来测试它.

如果您使用 gcc 以外的编译器编译代码怎么办？

好吧，那就这样吧，默认 ANSI 限制是针对标准 32 位字的。来自 ANSI C 标准第 5.2.4.2.1 段(整数类型的大小 <limits.h> ):

The values given below shall be replaced by constant expressions suitable for use in #if preprocessing directives. [...] Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

• number of bits for smallest object that is not a bit-field (byte)

  CHAR_BIT 8

POSIX 要求兼容平台具有 CHAR_BIT == 8 .

当然，对于没有 CHAR_BIT == 8 的机器，glibc 的假设可能会出错。 ，但请注意，您必须处于不寻常的架构下，并且不使用 gcc 并且您的平台不兼容 POSIX。不太可能。

但是请记住，“实现定义”意味着编译器编写者选择发生的情况。因此，即使您没有使用 gcc 进行编译，您的编译器有可能有某种 __CHAR_BIT__等效定义。即使 glibc 不会使用它，您也可以做一些研究并直接使用编译器的定义。这通常是不好的做法 - 您将编写针对特定编译器的代码。

请记住，您永远不应该弄乱系统头文件。当您使用错误且重要的常量(例如 CHAR_BIT )编译内容时，可能会发生非常奇怪的事情。 。这样做仅用于教育目的，并始终恢复原始文件。