C：使用64位对齐起始地址定义数组的便携式方法？

Question

对于在各种/未知架构/编译器（8/16/32/64位）上编译的代码，必须定义全局MEMPOOL数组：

uint8_t mempool[SIZE];

此mempool用于存储不同结构类型的对象，例如：

typedef struct Meta_t {
  uint16_t size;
  struct Meta_t *next;
  //and more
}

由于结构对象始终具有要与最大可能的边界保持一致，例如64字节必须确保在Mempool内部的那些结构对象之间添加填充字节：

struct Meta_t* obj = (struct Meta_t*) mempool[123] + padding;

这意味着如果结构对象在不对准的地址上启动对齐陷阱。

这在我的代码中已经很好。但是，我仍在寻找一种便携式方式来对齐Mempool Start地址。因为没有这些，就必须在数组启动地址和mempool内部第一个结构的地址之间插入填充字节。

到目前为止，我发现的唯一方法是将MEMPOOL定义在联合内部内部，并与另一个变量相结合，该变量无论如何都会由编译器对齐，但这应该是不可便携的。

不幸的是，对于嵌入式平台，我的代码还与ANSI C90编译器一起编译。实际上，我无法猜测哪些编译器完全使用。因此，我正在寻找一种绝对便携式的解决方案，我想任何类型的预处理器指令或编译器特定属性或语言功能无法使用C90之后

Answer 1

您可以使用_alignas，它是 C11标准，以强制特定的对齐方式。

_Alignas(uint64_t) uint8_t mempool[SIZE];

Answer 2

（struct meta_t*）mempool将导致不确定的行为，原因是比对齐更多 - 这也是严格的违法行为。

最好的解决方案可能是创建一个Union，例如：

typedef union
{
  struct Meta_t my_struct;
  uint8_t bytes[sizeof(struct Meta_t)];
} thing;

这同时解决了对齐和指针混音问题，并在C90中起作用。

现在，如果我们执行*（thing）mempool，那么这是明确的定义，因为此（lvalue）访问是通过包含uint8_t数组中的uint> uint8_t数组来完成的。在Union成员之间的类型punsing在C中也定义了。（C ++中不存在解决方案。）

Answer 3

不幸的是，这个...

此mempool用于存储不同结构类型的对象

...与此相结合...

我正在寻找一个绝对的便携式解决方案，我想任何类型的预处理器指令或编译器特定属性或语言功能无法使用C90之后

>

内容...除非您预先知道所有结构可以使用内存池的类型。即使您现在采用的方法也不严格符合C90，因为没有严格结合的方法来确定地址的对齐方式，以便计算需要多少填充。^*（您可能假设您可以将其转换为整数并查看最不重要的位，但是C不能保证您可以以这种方式确定任何有关对齐方式的方法。）

在实践中，有很多事情可以在尽管不严格符合C语言规范，但目标环境范围很广。将指针转换为整数作为机器地址的结果，以便将其用于对齐计算是一个明智的选择。为了适当地对准一个声明的数组，这将是：

#define MAX(x,y) (((x) < (y)) ? (y) : (x))
union max_align {
    struct d { long l; } l;
    struct l { double d; } d;
    struct p { void *p; } p;
    unsigned char bytes[MAX(MAX(sizeof(struct d), sizeof(struct l)), sizeof(struct p))];
};
#undef MAX

#define MEMPOOL_BLOCK_SIZE sizeof(union max_align)
union maxalign mempool[(size + MEMPOOL_BLOCK_SIZE - 1) / MEMPOOL_BLOCK_SIZE];

对于一系列非常大的C实现，这不仅可以确保池本身适当地对齐，以供严格结合的C90客户端使用，而且还可以方便地将池分为分配器可以绘制的对齐块。另请参阅@lundin的答案如何使用指针进入该池中的指针来避免严格的别名违规。

（如果您 do 碰巧知道必须确保对齐的所有类型，则将其中的每个类型都放入Union Max_align而不是d ，l和p，也可以通过将分配器发出指示为Union max_align而不是指向<代码来使您的生活更轻松> void或未签名的char。）

总体而言，您需要选择与绝对可移植性不同的目标。没有这样的东西。避免在C99中添加的编译器扩展和语言功能，后来是一个很好的开始。最大程度地减少您对实施行为的假设很重要。在不可行的地方，请选择您可以提出的最便携式选项，然后选择 文档 。

---

^*更不用说您依赖于不在C90中的uint8_t，即使所有C99及以后的实现也不一定都提供。