从未初始化的变量到memcpy是未定义的行为吗? [英] Is it undefined behaviour to memcpy from an uninitialized variable?

问题描述

是否使用未初始化的变量作为C中memcpy未定义行为的src?

Is using an uninitialized variable as the src for memcpy undefined behaviour in C?

void foo(int *to)
{
  int from;
  memcpy(to, &from, sizeof(from));
}

推荐答案

C委员会提议对

问题3的答案是库函数将展示 在不确定的值上使用时，行为不确定.

The answer to question 3 is that library functions will exhibit undefined behavior when used on indeterminate values.

如果确实存在这种情况，那么缺陷中的问题已寻求对memcpy和fwrite的豁免:

The question in the defect had sought an exemption for memcpy and fwrite if this was indeed the case saying:

[...]一个人希望能够复制未初始化的填充的事实 使用memcpy而未定义行为的结构中的字节是原因 使用未初始化对象的值不是未定义的 行为.这似乎表明一个结构的fwrite与 未初始化的填充字节不应表现出未定义的行为.

[...] The fact that one wants to be able to copy uninitialized padding bytes in structs using memcpy without undefined behavior is the reason that using the value of an uninitialized object is not undefined behavior. This seems to suggest that an fwrite of a struct with uninitialized padding bytes should not exhibit undefined behavior.

提议答复的这一部分似乎针对未初始化的填充:

This part of the propose response seems to be aimed at that concern over uninitialized padding:

委员会还注意到结构中的填充字节是 可能是摇晃的"表示形式的一种独特形式.

The committee also notes that padding bytes within structures are possibly a distinct form of "wobbly" representation.

我们可以看到缺陷报告338:C99似乎将不确定的值排除在未初始化的寄存器中，这与过去的预期有所不同.它说:"

We can see form defect report 338: C99 seems to exclude indeterminate value from being an uninitialized register this is somewhat of a change from past expectations. It says amongst other things:

[...]我 相信从陷阱中排除无符号字符类型的意图 表示是为了允许它被用来复制(通过memcpy) 任意内存，如果内存可能包含陷阱 某些类型的表示形式.[...]

[...] I believe the intent of excluding type unsigned char from having trap representations was to allow it to be used to copy (via memcpy) arbitrary memory, in the case that memory might contain trap representations for some types.[...]

博客文章阅读不确定的内容可能以及不确定的内容涵盖了很好地读取C语言中的不确定值的演变，并更加理解了我上面提到的更改.

The blog post Reading indeterminate contents might as well be undefined covers the evolution of reading indeterminate values in C well and make some more sense of the changes I mention above.

值得注意的是，这与C ++有所不同，在C ++中，从狭窄的无符号字符中读取不确定的值并不是未定义的行为， 缺陷报告240 注释区别:

It is worth noting this differs from C++ where reading an indeterminate value from a narrow unsigned char is not undefined behavior and defect report 240 notes this difference:

C委员会正在其DR338中处理类似的问题.根据这一分析，他们计划通过增加对左值到右值转换版本的描述来采取与上述方法几乎相反的方法. CWG认为，如果将未签名的char分配在寄存器中，并且因此需要重新评估提议的分辨率，则可能仍然会阻止对未签名的char的访问.另请参阅问题129.

The C committee is dealing with a similar issue in their DR338. According to this analysis, they plan to take almost the opposite approach to the one described above by augmenting the description of their version of the lvalue-to-rvalue conversion. The CWG did not consider that access to an unsigned char might still trap if it is allocated in a register and needs to reevaluate the proposed resolution in that light. See also issue 129.

这篇关于从未初始化的变量到memcpy是未定义的行为吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！