使用分配的 space 存储多个数组
Using an allocated space to store multiple arrays
下面的代码是否正确？
假设已知所有对象指针类型都具有相同的大小和对齐方式，且大小不大于 8。
// allocate some space to A, and set *A and **A to different regions of that space
char*** A = malloc(92);
*A = (char**)( (char*)A + 2*sizeof(char**) );
**A = (char*)*A + 4*sizeof(char*);
// initialize the second char** object
A[1] = *A + 2;
// write four strings further out in the space
strcpy(A[0][0],"string-0-0");
A[0][1] = A[0][0] + strlen(A[0][0]) + 1;
strcpy(A[0][1],"string-0-1");
A[1][0] = A[0][1] + strlen(A[0][1]) + 1;
strcpy(A[1][0],"string-1-0");
A[1][1] = A[1][0] + strlen(A[1][0]) + 1;
strcpy(A[1][1],"string-1-1");
我发现这样的东西在无法直接释放对象的情况下很有用。例如，假设 A[1][1] 可能会或可能不会重新分配给字符串文字的地址。无论哪种方式，您都可以释放 A。此外，对 malloc 的调用次数也已最小化。
我担心这可能不是正确的代码，原因如下。使用标准的草案版本，我有：
7.22.3 Memory management functions
- ...The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated)...
所以我保证能够使用 space 作为单一类型的数组。我找不到任何可以将其用作两种不同类型（char* 和 char**）的数组的保证。请注意，使用某些 space 作为字符数组是独一无二的，因为任何对象都可以作为字符类型数组访问。
有效类型的规则与此方法一致，因为没有单独的字节被用作两种不同类型的一部分。
虽然上面表明似乎没有明显违反标准，但标准也没有明确允许这种行为，我们有第 4 章第 2 段（强调）：
If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint or runtime constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe ‘‘behavior that is undefined’’.
当内存模型本身如此模糊时，这有点模糊。使用 malloc() 返回的 space 来存储任何（一个）类型的数组显然需要明确的允许，我在上面引用了该允许。因此，有人可能会争辩说，将 space 用于不同类型的不相交数组也需要明确的允许，如果没有它，将作为第 4 章的未定义行为留下。
所以，具体来说，如果代码示例是正确的，那么根据上面引用的标准第 4 章的部分，它没有明确定义因此未定义的论点有什么问题？
假设任何对象从分配区域开始的偏移量是对齐的倍数，并且假设在分配的生命周期内没有内存块被用作超过一种类型，那么没问题。
一个令人讨厌的陷阱是，虽然有一些算法（例如哈希 tables）可以很好地与 table 一起工作，该 table 最初填充了任意值（给定一个值可能正确也可能不正确，代码可能能够更快地确定该值是否正确——O(1) vs O(N)——比它在没有初始猜测的情况下找到正确的值），这样的行为可能使用 gcc 或 clang 时不可靠。他们解释标准的方式，将内存写入一种类型并读取另一种非字符类型会产生未定义的行为，即使目标类型没有陷阱表示，即使转换为新类型的指针从未使用过（以其原始形式）在那之后，即使代码对任何值都能正确工作，在数据尚未作为新类型写入的情况下，读取可能已经产生。
鉴于：
float *fp;
uint32_t *ip;
*fp = 1.0f;
*ip = 23;
如果 fp 和 ip 标识相同的存储，则行为将被定义，并且
之后需要存储以容纳 23。另一方面，给定：
float *fp;
uint32_t *ip;
*fp = 1.0f;
uint32_t temp = *ip;
*ip = 23;
编译器可以利用未定义行为重新排序
操作，因此写入 *fp 发生在写入 *ip 之后。如果数据被重新用于哈希 table 之类的东西，编译器不太可能能够有效地应用这种优化，但是 "smart" 编译器可能会在写入有用数据之后重新排序无用数据的写入.这样的 "optimizations" 不太可能破坏事物，但没有标准定义的方法来防止它们，除非通过释放和重新分配存储（如果使用托管系统并且可以容忍性能影响和可能的碎片）或者在重新使用之前清除存储（这可能会将 O(1) 操作转换为 O(N)）。
下面的代码是否正确？
假设已知所有对象指针类型都具有相同的大小和对齐方式，且大小不大于 8。
// allocate some space to A, and set *A and **A to different regions of that space
char*** A = malloc(92);
*A = (char**)( (char*)A + 2*sizeof(char**) );
**A = (char*)*A + 4*sizeof(char*);
// initialize the second char** object
A[1] = *A + 2;
// write four strings further out in the space
strcpy(A[0][0],"string-0-0");
A[0][1] = A[0][0] + strlen(A[0][0]) + 1;
strcpy(A[0][1],"string-0-1");
A[1][0] = A[0][1] + strlen(A[0][1]) + 1;
strcpy(A[1][0],"string-1-0");
A[1][1] = A[1][0] + strlen(A[1][0]) + 1;
strcpy(A[1][1],"string-1-1");
我发现这样的东西在无法直接释放对象的情况下很有用。例如，假设 A[1][1] 可能会或可能不会重新分配给字符串文字的地址。无论哪种方式，您都可以释放 A。此外，对 malloc 的调用次数也已最小化。
我担心这可能不是正确的代码，原因如下。使用标准的草案版本，我有：
7.22.3 Memory management functions
- ...The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object with a fundamental alignment requirement and then used to access such an object or an array of such objects in the space allocated (until the space is explicitly deallocated)...
所以我保证能够使用 space 作为单一类型的数组。我找不到任何可以将其用作两种不同类型（char* 和 char**）的数组的保证。请注意，使用某些 space 作为字符数组是独一无二的，因为任何对象都可以作为字符类型数组访问。
有效类型的规则与此方法一致，因为没有单独的字节被用作两种不同类型的一部分。
虽然上面表明似乎没有明显违反标准，但标准也没有明确允许这种行为，我们有第 4 章第 2 段（强调）：
If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint or runtime constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe ‘‘behavior that is undefined’’.
当内存模型本身如此模糊时，这有点模糊。使用 malloc() 返回的 space 来存储任何（一个）类型的数组显然需要明确的允许，我在上面引用了该允许。因此，有人可能会争辩说，将 space 用于不同类型的不相交数组也需要明确的允许，如果没有它，将作为第 4 章的未定义行为留下。
所以，具体来说，如果代码示例是正确的，那么根据上面引用的标准第 4 章的部分，它没有明确定义因此未定义的论点有什么问题？
假设任何对象从分配区域开始的偏移量是对齐的倍数，并且假设在分配的生命周期内没有内存块被用作超过一种类型，那么没问题。
一个令人讨厌的陷阱是，虽然有一些算法（例如哈希 tables）可以很好地与 table 一起工作，该 table 最初填充了任意值（给定一个值可能正确也可能不正确，代码可能能够更快地确定该值是否正确——O(1) vs O(N)——比它在没有初始猜测的情况下找到正确的值），这样的行为可能使用 gcc 或 clang 时不可靠。他们解释标准的方式，将内存写入一种类型并读取另一种非字符类型会产生未定义的行为，即使目标类型没有陷阱表示，即使转换为新类型的指针从未使用过（以其原始形式）在那之后，即使代码对任何值都能正确工作，在数据尚未作为新类型写入的情况下，读取可能已经产生。
鉴于：
float *fp;
uint32_t *ip;
*fp = 1.0f;
*ip = 23;
如果 fp 和 ip 标识相同的存储，则行为将被定义，并且 之后需要存储以容纳 23。另一方面，给定：
float *fp;
uint32_t *ip;
*fp = 1.0f;
uint32_t temp = *ip;
*ip = 23;
编译器可以利用未定义行为重新排序 操作，因此写入 *fp 发生在写入 *ip 之后。如果数据被重新用于哈希 table 之类的东西，编译器不太可能能够有效地应用这种优化，但是 "smart" 编译器可能会在写入有用数据之后重新排序无用数据的写入.这样的 "optimizations" 不太可能破坏事物，但没有标准定义的方法来防止它们，除非通过释放和重新分配存储（如果使用托管系统并且可以容忍性能影响和可能的碎片）或者在重新使用之前清除存储（这可能会将 O(1) 操作转换为 O(N)）。