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))来确保使用与Microsoft编译器可以使用的恶作剧兼容的正确结构打包。

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

如果是，什么时候？

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

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

然后他可以做任何他想做的事。但是，如果您确实愿意，您可以告知您的共享库遵循一些通用的ABI标准。

如果我对库和测试程序使用不同的编译器怎么办？

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

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

共享库中位域的可移植性

3 个答案: