There are certain situations in which uninitialized memory may be safely read using type "unsigned char*" [e.g. a buffer returned from malloc]. Code may read such memory without having to worry about the compiler throwing causality out the window, and there are times when it may be more efficient to have code be prepared for anything memory might contain than to ensure that uninitialized data won't be read (a commonplace example of this would be using memcpy on partially-initialized buffer rather than discretely copying all of the elements that contain meaningful data).

然而，即使在这种情况下，人们也应该始终假设，如果字节的任何组合特别烦人，那么读取它总是会产生字节的模式(如果某个模式在生产中是烦人的，但在开发中不是，那么这种模式直到代码进入生产中才会出现)。

Reading uninitialized memory might be useful as part of a random-generation strategy in an embedded system where one can be sure the memory has never been written with substantially-non-random content since the last time the system was powered on, and if the manufacturing process used for the memory causes its power-on state to vary in semi-random fashion. Code should work even if all devices always yield the same data, but in cases where e.g. a group of nodes each need to select arbitrary unique IDs as quickly as possible, having a "not very random" generator which gives half the nodes the same initial ID might be better than not having any initial source of randomness at all.

如果操作得当，使用未初始化的数据来获得随机性并不一定是件坏事。事实上，OpenSSL正是这样做的，以播种它的PRNG。

显然，这种用法并没有很好地记录下来，因为有人注意到Valgrind抱怨使用未初始化的数据，并“修复”了它，导致了PRNG中的一个错误。

所以你可以这样做，但你需要知道你在做什么，并确保任何阅读你的代码的人都理解这一点。

让我说清楚一点:我们不会在程序中调用未定义的行为。这从来都不是一个好主意，就这样。这条规则很少有例外;例如，如果您是实现offsetof的库实现者。如果您的情况属于这种例外，您可能已经知道这一点。在这种情况下，我们知道使用未初始化的自动变量是未定义的行为。

编译器对未定义行为的优化变得非常积极，我们可以发现许多未定义行为导致安全缺陷的情况。最臭名昭著的例子可能是Linux内核空指针检查删除，我在回答c++编译错误时提到过?围绕未定义行为的编译器优化将有限循环变成无限循环。

我们可以阅读CERT的危险优化和因果关系的损失(视频)，其中说:

Increasingly, compiler writers are taking advantage of undefined behaviors in the C and C++ programming languages to improve optimizations. Frequently, these optimizations are interfering with the ability of developers to perform cause-effect analysis on their source code, that is, analyzing the dependence of downstream results on prior results. Consequently, these optimizations are eliminating causality in software and are increasing the probability of software faults, defects, and vulnerabilities.

特别是关于不确定值，C标准缺陷报告451:未初始化自动变量的不稳定性是一些有趣的阅读。它还没有解决，但引入了不稳定值的概念，这意味着值的不确定性可能在程序中传播，并且在程序的不同位置可能有不同的不确定值。

我不知道有什么例子会发生这种情况，但在这一点上，我们不能排除这种可能性。

真实的例子，而不是你期望的结果

你不太可能得到随机值。编译器可以优化整个循环。例如，用这个简化的例子:

void updateEffect(int  arr[20]){
    for(int i=0;i<20;i++){
        int r ;    
        arr[i] = r ;
    }
}

Clang优化了它(看现场):

updateEffect(int*):                     # @updateEffect(int*)
    retq

或者可能得到全0，就像这个修改后的情况:

void updateEffect(int  arr[20]){
    for(int i=0;i<20;i++){
        int r ;    
        arr[i] = r%255 ;
    }
}

现场观看:

updateEffect(int*):                     # @updateEffect(int*)
    xorps   %xmm0, %xmm0
    movups  %xmm0, 64(%rdi)
    movups  %xmm0, 48(%rdi)
    movups  %xmm0, 32(%rdi)
    movups  %xmm0, 16(%rdi)
    movups  %xmm0, (%rdi)
    retq

这两种情况都是完全可以接受的未定义行为形式。

注意，如果我们在一个Itanium上，我们可能会得到一个trap值:

[…]如果寄存器恰好保存了一个特殊的“not-a-thing”值， 读取寄存器陷阱，除了一些指令[…]

其他重要事项

有趣的是，在UB Canaries项目中，gcc和clang在利用未初始化内存的未定义行为方面存在差异。文章指出(重点是我的):

Of course we need to be completely clear with ourselves that any such expectation has nothing to do with the language standard and everything to do with what a particular compiler happens to do, either because the providers of that compiler are unwilling to exploit that UB or just because they have not gotten around to exploiting it yet. When no real guarantee from the compiler provider exists, we like to say that as-yet unexploited UBs are time bombs: they’re waiting to go off next month or next year when the compiler gets a bit more aggressive.

正如Matthieu M.指出的，每个C程序员应该知道的关于未定义行为#2/3也与这个问题有关。它说了很多(重点是我的):

The important and scary thing to realize is that just about any optimization based on undefined behavior can start being triggered on buggy code at any time in the future. Inlining, loop unrolling, memory promotion and other optimizations will keep getting better, and a significant part of their reason for existing is to expose secondary optimizations like the ones above. To me, this is deeply dissatisfying, partially because the compiler inevitably ends up getting blamed, but also because it means that huge bodies of C code are land mines just waiting to explode.

为了完整起见，我可能应该提到实现可以选择使未定义的行为定义良好，例如gcc允许类型双关语通过联合，而在c++中这似乎是未定义的行为。如果是这种情况，实现应该记录它，这通常是不可移植的。

在任何想要使用未初始化变量的地方使用7757。我从质数列表中随机选择了它:

这是被定义的行为 它保证不总是0 它是质数 它很可能在统计上是随机的，就像未初始化一样 变量 它可能比未初始化的变量快，因为它的 值在编译时已知

真的不好!坏习惯，坏结果。 考虑:

A_Function_that_use_a_lot_the_Stack();
updateEffect();

如果函数A_Function_that_use_a_lot_the_Stack()总是进行相同的初始化，则堆栈上保留相同的数据。这些数据就是我们调用updateEffect()得到的:总是相同的值!

好问题!

未定义并不意味着它是随机的。考虑一下，在全局未初始化变量中获得的值是由系统或您的/其他应用程序运行时遗留在那里的。根据您的系统对不再使用的内存的处理和/或系统和应用程序生成的值类型，您可能会得到:

总是一样的。 成为一小部分价值观中的一员。 获取一个或多个小范围内的值。 在16/32/64位系统的指针上看到许多可以被2/4/8整除的值 .．.

您将得到的值完全取决于系统和/或应用程序留下的非随机值。因此，确实会有一些噪音(除非您的系统删除不再使用的内存)，但您将从中提取的值池绝不是随机的。

对于局部变量，情况会变得更糟，因为它们直接来自您自己程序的堆栈。在执行其他代码期间，您的程序很有可能实际编写这些堆栈位置。我估计在这种情况下运气的机会非常低，而你所做的“随机”代码更改将尝试这种运气。

阅读随机性。正如你所看到的，随机性是一种非常特殊且难以获得的属性。一个常见的错误是，如果你只是采取一些难以跟踪的东西(比如你的建议)，你会得到一个随机的值。