共享库中的位域可移植性

Question

我很难理解 C 中位字段的可移植性。假设我有一个共享库，仅由两个文件组成，libfoobar.h（公共标头）和libfoobar.c，内容如下：

libfoobar.h:

typedef struct some_bitfield_T {
    unsigned char foo:3;
    unsigned char bar:2;
    unsigned char tree:2;
    unsigned char window:1;
} some_bitfield;

extern unsigned int some_function (some_bitfield input);

libfoobar.c:

#include "libfoobar.h"

unsigned int some_function (some_bitfield input) {
    return input.foo * 3 + input.bar + input.tree + 1 - input.window;
}

编译并安装库后，我使用名为test 的程序对其进行测试。

test.c:

#include <stdio.h>
#include <libfoobar.h>

int main () {
    some_bitfield my_attempt = {
        .foo = 6,
        .bar = 3,
        .tree = 1,
        .window = 1
    };
    unsigned int some_number = some_function(my_attempt);
    printf("Here is the result: %u\n", some_number);
    return 0;
}

上面的test 程序是否有可能产生与以下输出不同的任何东西？

Here is the result: 22

如果是，什么时候？如果库是由我以外的其他人编译的怎么办？如果我为库和test 程序使用不同的编译器会怎样？

Answer 1

这里是 C11 标准的相关部分：

实现可以分配任何大到足以容纳位域的可寻址存储单元。如果有足够的空间，结构中紧跟在另一个位域之后的位域将被打包到同一单元的相邻位中。如果剩余空间不足，则将不适合的位域放入下一个单元还是与相邻单元重叠是实现定义的。单元内位域的分配顺序（高位到低位或低位到高位）是实现定义的。未指定可寻址存储单元的对齐方式。

§6.7.2.1 第 11 点。

这意味着编译器可以使用它喜欢的任何合适的类型来保存位域，并且它们将按照定义的顺序与每个位域相邻。

但是，编译器可以自行选择是从高到低还是从低到高排序。如果空间不足，它还可以选择重叠位域或分配新的存储单元（在您的情况下这不是问题，您只有 8 位）。

考虑到上述情况，我们可以回答您的问题。如果程序和库是使用相同编译器实现编译的，您可以仅保证您的测试程序将给出正确的答案。如果您使用两种不同的编译器，即使它们都使用（比如）unsigned char 来存储位字段，一个可以从字节的顶部开始，另一个可以从底部开始。

实际上，正如上面的 ensc 所说，平台 ABI 可能会定义一个位字段打包和排序标准，这使得同一平台上的编译器之间可以正常工作，但原则上并不能保证。

Answer 2

位域是实现定义的，不可移植。但是对于大多数相关平台，它们的提取/打包由 ABI 明确指定，以便它们可以安全地用于共享库中。

例如：

• ARM EABI 在 7.1.7 “位域”中指定它们。
• i386 ABI 在第 3-6 页上指定它们
• x86-64 在第 15+ 页上指定它们
• MIPS 在第 3-7 页上指定了它们

Answer 3

我很难理解 C 中位域的可移植性

好吧，没什么好理解的 - 位域不可移植。

上面的测试程序是否有可能产生与下面的输出不同的东西？

最常见的情况是用户空间和内核空间之间的通信。有时通信使用指向结构的指针。由库实现者编写的标头，如 glibc，包装内核系统调用有时会重复在内核源代码树中定义的相同结构。为了正确通信，这些结构中的填充必须在两边都相同 - 在内核编译时在内核一侧，在我们高兴地编译我们自己的项目时在用户空间一侧，即使在内核编译多年后。

在大多数架构 + 操作系统上，都存在一个“ABI”——一组规则，这些规则还确定应如何填充结构以及应如何打包位域。编译器可能遵守该 ABI 或不遵守。当 gcc 用于从 linux 交叉编译 windows 时，例如。需要使用__attribute__ ((ms_struct)) 来确保使用与微软编译器的恶作剧兼容的正确结构封装。

所以回答：Is there any possibility - 当然存在，不同的编译器标志或设置可能会导致结构成员之间的打包或填充不同所以我可以用gcc -fpack-struct=100 编译程序，你用gcc -fpack-struct=20 编译你的共享库和哎呀。但这不仅限于结构填充 - 其他人可以使用具有 64 位而不是 32 位的 unsigned int 编译您的程序，因此函数的返回值可能是意外的。

如果是，什么时候？

当使用不兼容的代码生成方法创建依赖指定 ABI 进行通信的机器代码时。从实际的角度来看，这曾经发生过吗？每个 linux 系统在/usr/lib 中都有 吨 个共享库。

如果库是由我以外的其他人编译的怎么办？

然后他可以为所欲为。但是，如果您真的愿意，您可以传达您的共享库遵循一些常见的 ABI 标准。

如果我为库和测试程序使用不同的编译器会怎样？

然后请务必阅读该编译器文档，以确保它遵循您需要的通用 ABI。

阅读：How to Write Shared Libraries. Ulrich Drepper - 第 3 节似乎是相关的。