memcpy 与 C 中的分配——应该是 memmove 吗？

Question

正如an answer to this question 中所指出的，编译器（在本例中是 gcc-4.1.2，是的，它很旧，不，我无法更改它）可以在它认为合适的地方用 memcpy 替换结构分配。

我在 valgrind 下运行一些代码并收到有关 memcpy 源/目标重叠的警告。当我查看代码时，我看到了这个（释义）：

struct outer
{
    struct inner i;
    // lots of other stuff
};

struct inner
{
    int x;
    // lots of other stuff
};

void frob(struct inner* i, struct outer* o)
{
    o->i = *i;
}

int main()
{
    struct outer o;

    // assign a bunch of fields in o->i...

    frob(&o.i, o);
    return 0;
}

如果 gcc 决定用 memcpy 替换该分配，那么这是一个无效的调用，因为源和目标重叠。

显然，如果我将frob 中的赋值语句改为调用memmove，那么问题就消失了。

但这是一个编译器错误，还是该赋值语句在某种程度上无效？

Answer 1

我认为您混淆了级别。 gcc 通过调用任何它喜欢的库函数来替换赋值操作是完全正确的，只要它可以保证正确的行为。

这不是“调用”memcpy 或标准意义上的任何东西。它只是使用它的库中的一个函数，它可能有额外的信息来保证正确性。标准中描述的memcpy 的属性是被视为程序员接口的属性，而不是编译器/环境实现者的接口。

memcpy 在相关实现中是否实现了使其对赋值操作有效的行为是另一个问题。检查甚至检查代码应该不难。

Answer 2

据我所知，这是一个编译器错误。根据别名规则，i 被允许为&o.i 别名，因为类型匹配并且编译器无法证明o.i 的地址以前不能被占用。当然，使用重叠（或相同）指针调用 memcpy 会调用 UB。

请注意，在您的示例中，o->i 是无稽之谈。你的意思是o.i 我想...

Answer 3

我想有一个错字：“&o”而不是“0”。 在这个假设下，“重叠”实际上是一个严格的覆盖：memcpy(&o->i,&o->i,sizeof(o->i))。在这种特殊情况下，memcpy 的行为正确。