问题：

void**是严格别名规则的例外吗？

王成化

2023-03-14

基本上，当启用严格别名时，此代码是否合法？

void f(int *pi) {
    void **pv = (void **) &pi;
    *pv = NULL;
}

这里，我们通过另一种类型的指针（指向＜code＞void*＜/code＞的指针）访问一种类型（＜code＜int*＜/code＞）的对象，因此我认为这确实是一种严格的别名冲突。

但是，试图突出未定义行为的样本使我怀疑（即使它不能证明它是合法的）。

首先，如果我们将＜code＞int*＜/code＞和＜code＞char*＜/code＞别名，我们可以根据优化级别获得不同的值（因此这绝对是一种严格的别名冲突）：

#include <stdio.h>

static int v = 100;

void f(int **a, char **b) {
    *a = &v;
    *b = NULL;
    if (*a)
        // *b == *a (NULL)
        printf("Should never be printed: %i\n", **a);
}

int main() {
    int data = 5;
    int *a = &data;
    f(&a, (char **) &a);
    return 0;
}

$ gcc a.c && ./a.out
$ gcc -O2 -fno-strict-aliasing a.c && ./a.out
$ gcc -O2 a.c && ./a.out
Should never be printed: 100

但是，使用 void ** 而不是 char ** 的相同示例不会表现出未定义的行为：

#include <stdio.h>

static int v = 100;

void f(int **a, void **b) {
    *a = &v;
    *b = NULL;
    if (*a)
        // *b == *a (NULL)
        printf("Should never be printed: %i\n", **a);
}

int main() {
    int data = 5;
    int *a = &data;
    f(&a, (void **) &a);
    return 0;
}

$ gcc a.c && ./a.out
$ gcc -O2 -fno-strict-aliasing a.c && ./a.out
$ gcc -O2 a.c && ./a.out

这是偶然的吗？或者void**的标准中是否有明确的例外？

或者可能只是编译器专门处理< code>void **,因为实际上< code>(void **)

共有3个答案

弓玉书

2023-03-14

虽然char*和void*需要具有匹配的表示，但某些平台对int*使用不同的表示。因此，任何依赖于使用取消引用的void**来互换访问所有指针类型的能力的代码都不会移植到此类机器上，并且从标准的角度来看是“不可移植的”。因此，标准放弃了任何特定实现是否应该支持此类构造的管辖权。这样做的实现比不这样做的实现更适合低级编程，因此设计和配置为适合该目的的高质量实现也会这样做。然而，请注意，clang和gcc都不是为了特别适合低级编程而设计的，除非使用-fno-严格-混淆现象标志。

为了澄清为什么平台可能对 int* 和 char* 使用不同的表示形式，某些硬件平台不允许以小于 16 位的块直接寻址内存。该标准将允许此类平台的编译器以各种方式存储内容，在性能，存储效率和与期望char为8位的代码的兼容性之间进行不同的权衡：

只需使char与最小的直接存储单元的大小相匹配（例如，使char和int都为16位）。我使用了一个编译器来做到这一点。这种方法可能会提供最佳性能，但是使用大量无符号字符数组来保存八位字节的代码将浪费其一半的存储空间。

在每个char中存储8位有用的数据，剩下8位未使用。将16位值拆分为两个字，将32位值拆分为四个字。这将提供出色的兼容性，但性能和存储效率很差。

将< code>char*实现为一个指向16位字的指针、一个指示它应该标识该字的哪一半的位以及15个填充位的组合，但是将< code>int*实现为一个指向16位字的指针。

如上实现char*，但在int*中添加一个填充字节。这将提高兼容性，但浪费一些存储空间。

没有一种方法对所有应用程序都是最好的，但是该标准允许实现选择对客户最有用的一种或多种方法(可能可以通过命令行开关选择)。