C中的接口

Question

我正在设计一个应用程序，但遇到了一个实施问题。我有以下结构定义：

app.h:

struct application_t{
    void (*run_application)(struct application_t*);
    void (*stop_application)(struct application_t*);
}

struct application_t* create();

当我试图“实现”这个application_t 时，问题就来了。我倾向于定义另一个结构：

app.c:

struct tcp_application_impl_t{
    void (*run_application)(struct application_t*);
    void (*stop_application)(struct application_t*);
    int client_fd;
    int socket_fd;
}

struct application_t* create(){
     struct tcp_application_impl_t * app_ptr = malloc(sizeof(struct tcp_application_impl_t));
     //do init
     return (struct application_t*) app_ptr;
}

所以如果我按如下方式使用：

#include "app.h"

int main(){
    struct application_t *app_ptr = create();
    (app_ptr -> run_application)(app_ptr);    //Is this behavior well-defined?
    (app_ptr -> stop_application)(app_ptr);   //Is this behavior well-defined?
}

让我感到困惑的问题是，如果我打电话给(app_ptr -> run_application)(app_ptr); yields UB。

app_ptr 的“静态类型”如果struct application_t*，但“动态类型”是struct tcp_application_impl_t*。 struct application_t 和 struct tcp_application_t 与 N1570 6.2.7(p1) 不兼容：

他们的成员之间应该有一对一的通信，例如 每对对应的成员都声明为 compatible 类型

在这种情况下显然不是真的。

您能否提供解释该行为的标准参考？

Answer 1

您的两个结构不兼容，因为它们是不同的类型。您已经找到了“兼容类型”一章，它定义了使两个结构兼容的原因。当您使用指向错误类型的指针访问这些结构时，UB 稍后会出现，严格按照 6.5/7 的别名违规。

解决这个问题的明显方法是：

struct tcp_application_impl_t{
    struct application_t app;
    int client_fd;
    int socket_fd;
}

现在类型可以别名了，因为 tcp_application_impl_t 是一个聚合，在其成员中包含一个 application_t。

另一种明确定义的方法是使用隐藏在 C17 6.5.2.3/6 中的“联合通用初始序列”的特殊规则：

一个特殊的保证是为了简化联合的使用：如果联合包含 几个结构共享一个共同的初始序列（见下文），如果联合 对象当前包含这些结构之一，允许检查常见的 它们中任何一个的初始部分，任何地方的完整类型的声明 可见。如果对应的成员，两个结构共享一个共同的初始序列 对于一个或多个初始成员的序列，具有兼容的类型（对于位域，具有相同的宽度）。

这将允许您在声明它们时使用原始类型。但是在同一个翻译单元的某个地方，你必须添加一个虚拟联合 typedef 来利用上述规则：

typedef union
{
  struct application_t app;
  struct tcp_application_impl_t impl;
} initial_sequence_t;

你不需要实际使用这个联合的任何实例，它只需要坐在那里可见。这告诉编译器这两种类型可以使用别名，只要它们共同的初始序列。在您的情况下，这意味着函数指针，而不是 tcp_application_impl_t 中的尾随变量。

编辑：

免责声明。常见的初始序列技巧显然有点争议，编译器使用它做的事情超出了委员会的预期。并且可能在 C 和 C++ 中的工作方式不同。见union 'punning' structs w/ "common initial sequence": Why does C (99+), but not C++, stipulate a 'visible declaration of the union type'?

Answer 2

如果“严格别名规则”(N1570 6.5p7) 仅被解释为指定事物可能别名的情况（这似乎是作者的意图，因为脚注 88 表示“此列表的意图是指定对象可能被别名或可能不被别名的那些情况”）像你这样的代码应该没有问题，前提是在使用两种不同类型的左值访问对象的所有上下文中，所涉及的左值之一是明显新派生的来自另一个。

6.5p7 唯一有意义的方法是，如果涉及从其他对象新可见派生的对象的操作被识别为对原始对象的操作。然而，何时承认这种派生的问题留给了实施质量问题，并认为市场将比委员会更好地判断什么是适合某些特定的“质量”实施的必要条件目的。

如果目标是编写可在配置为遵循脚注 88 的明确意图的实现上运行的代码，那么只要对象没有别名，就应该是安全的。支持这一要求可能需要确保编译器可以看到指针彼此相关，或者它们每个都是从使用点的公共对象新派生的。给定，例如

thing1 *p1 = unionArray[i].member1;
int v1 = p1->x;
thing2 *p2 = unionArray[j].member2;
p2->x = 31;
thing1 *p3 = unionArray[i].member1;
int v2 = p3->x;

每个指针都将在新派生自unionArray 的上下文中使用，因此即使i==j 也不会有别名。即使在启用-fstrict-aliasing 的情况下，像“icc”这样的编译器也不会出现此类代码的问题，但是因为 gcc 和 clang 都将 6.5p7 的要求强加给程序员，即使在不涉及别名的情况下，他们也不会正确处理它。

请注意，如果代码是：

thing1 *p1 = unionArray[i].member1;
int v1 = p1->x;
thing2 *p2 = unionArray[j].member2;
p2->x = 31;
int v2 = p1->x;

那么p1 的第二次使用将在i==j 的情况下别名p2，因为p2 将通过不涉及p1 的方式访问与p1 关联的存储，在时间p1 之间形成和最后一次使用（因此别名为p1）。

根据标准的作者，C 精神包括“信任程序员”和“不要阻止程序员做需要做的事情”的原则。除非有特殊需要来处理不特别适合人们所做的实现的限制，否则应该以适合自己目的的方式针对维护 C 精神的实现。 icc 处理的-fstrict-aliasing 方言，或icc、gcc 和clang 处理的-fno-strict-aliasing 方言应该适合您的用途。 gcc 和 clang 的 -fstrict-aliasing 方言应该被认为根本不适合您的目的，并且不值得定位。