正如其他人所注意到的，这就是未定义行为(UB)。

实际上，它(可能)实际上(有点)管用。在x86[-64]架构上读取未初始化的寄存器确实会产生垃圾结果，而且可能不会做任何坏事(与例如Itanium相反，那里的寄存器可以被标记为无效，因此读取会传播NaN之类的错误)。

但这里存在两个主要问题:

It won't be particularly random. In this case, you're reading from the stack, so you'll get whatever was there previously. Which might be effectively random, completely structured, the password you entered ten minutes ago, or your grandmother's cookie recipe. It's Bad (capital 'B') practice to let things like this creep into your code. Technically, the compiler could insert reformat_hdd(); every time you read an undefined variable. It won't, but you shouldn't do it anyway. Don't do unsafe things. The fewer exceptions you make, the safer you are from accidental mistakes all the time.

UB更紧迫的问题是它使整个程序的行为没有定义。现代编译器可以使用它来省略大量的代码，甚至可以回溯到过去。玩UB就像维多利亚时代的工程师拆除一个活跃的核反应堆。有无数的事情会出错，而且您可能连一半的基本原则或实现的技术都不知道。这可能没什么，但你仍然不应该让它发生。看看其他漂亮的答案来了解细节。

还有，我会炒了你。

还有一种可能性需要考虑。

现代编译器(嗯，g++)非常聪明，它们会检查你的代码，看看哪些指令影响状态，哪些不影响状态，如果一条指令被保证不影响状态，g++会简单地删除那条指令。

接下来会发生什么。g++肯定会看到你正在读取，执行算术运算，保存，本质上是一个垃圾值，这会产生更多的垃圾。因为不能保证新的垃圾会比旧的垃圾更有用，所以它只会让你的循环消失。杂音!

这个方法很有用，但下面是我要做的。结合UB(未定义行为)与rand()速度。

当然，reduce rand()被执行了，但是把它们混合在一起，这样编译器就不会做任何你不希望它做的事情。

我也不会解雇你。

让我说清楚一点:我们不会在程序中调用未定义的行为。这从来都不是一个好主意，就这样。这条规则很少有例外;例如，如果您是实现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++中这似乎是未定义的行为。如果是这种情况，实现应该记录它，这通常是不可移植的。

正如这里大多数人提到的未定义行为。未定义也意味着你可以得到一些有效的整数值(幸运的是)，在这种情况下，这将更快(因为rand函数调用没有进行)。 但不要实际使用它。我相信这将会带来可怕的结果，因为运气并不总是伴随着你。

正如其他人所注意到的，这就是未定义行为(UB)。

实际上，它(可能)实际上(有点)管用。在x86[-64]架构上读取未初始化的寄存器确实会产生垃圾结果，而且可能不会做任何坏事(与例如Itanium相反，那里的寄存器可以被标记为无效，因此读取会传播NaN之类的错误)。

但这里存在两个主要问题:

It won't be particularly random. In this case, you're reading from the stack, so you'll get whatever was there previously. Which might be effectively random, completely structured, the password you entered ten minutes ago, or your grandmother's cookie recipe. It's Bad (capital 'B') practice to let things like this creep into your code. Technically, the compiler could insert reformat_hdd(); every time you read an undefined variable. It won't, but you shouldn't do it anyway. Don't do unsafe things. The fewer exceptions you make, the safer you are from accidental mistakes all the time.

UB更紧迫的问题是它使整个程序的行为没有定义。现代编译器可以使用它来省略大量的代码，甚至可以回溯到过去。玩UB就像维多利亚时代的工程师拆除一个活跃的核反应堆。有无数的事情会出错，而且您可能连一半的基本原则或实现的技术都不知道。这可能没什么，但你仍然不应该让它发生。看看其他漂亮的答案来了解细节。

还有，我会炒了你。

我做了一个非常简单的测试，它根本不是随机的。

#include <stdio.h>

int main() {

    int a;
    printf("%d\n", a);
    return 0;
}

每次我运行程序，它都输出相同的数字(在我的例子中是32767)——没有比这更随机的了。这大概是运行时库中留在堆栈上的启动代码。由于每次程序运行时都使用相同的启动代码，并且在两次运行之间程序中没有其他变化，因此结果是完全一致的。