不以根用户或其他特权用户身份运行程序不会对任何系统造成损害，因此通常这可能是一个好主意。

通过将数据写入某个随机的内存位置，你不会直接“破坏”计算机上运行的任何其他程序，因为每个进程都运行在自己的内存空间中。

如果你试图访问任何没有分配给你的进程的内存，操作系统将停止你的程序执行分割错误。

因此，直接(无需以根用户身份运行并直接访问/dev/mem之类的文件)，您的程序不会干扰在您的操作系统上运行的任何其他程序。

尽管如此——这可能是你听说过的危险——盲目地将随机数据写入随机的内存位置，你肯定会损坏任何你能损坏的东西。

例如，您的程序可能希望删除存储在程序某处的文件名所给出的特定文件。如果你不小心覆盖了文件名所在的位置，你可能会删除一个完全不同的文件。

除了你自己的程序，我不认为你会破坏任何东西，在最坏的情况下，你会尝试从一个内存地址读取或写入一个页面，内核没有分配给你的进程，产生适当的异常并被杀死(我的意思是，你的进程)。

我正在使用一个用于DSP芯片的编译器，该编译器故意生成代码，从C代码中访问一个数组的末尾，而C代码没有!

这是因为循环是结构化的，因此迭代结束时将为下一次迭代预取一些数据。因此，在最后一次迭代结束时预取的数据实际上从未被使用。

编写这样的C代码会调用未定义的行为，但这只是一个标准文档的形式，它关注的是最大的可移植性。

更常见的情况是，访问越界的程序没有被巧妙地优化。它只是有bug。代码获取一些垃圾值，并且与前面提到的编译器的优化循环不同，代码随后在后续计算中使用该值，从而破坏了它们。

捕获这样的错误是值得的，因此即使仅仅为了这个原因，也值得使行为未定义:这样运行时就可以产生类似“main.c第42行数组溢出”这样的诊断消息。

在具有虚拟内存的系统上，分配数组时，后面的地址可能位于虚拟内存的未映射区域。访问将轰炸程序。

说句题外话，请注意，在C语言中，我们允许创建一个指针，它位于数组的末尾之后。这个指针必须比任何指向数组内部的指针都要大。 这意味着C实现不能将数组放在内存的末尾，在那里，1 +地址会被环绕，看起来比数组中的其他地址更小。

Nevertheless, access to uninitialized or out of bounds values are sometimes a valid optimization technique, even if not maximally portable. This is for instance why the Valgrind tool does not report accesses to uninitialized data when those accesses happen, but only when the value is later used in some way that could affect the outcome of the program. You get a diagnostic like "conditional branch in xxx:nnn depends on uninitialized value" and it can be sometimes hard to track down where it originates. If all such accesses were trapped immediately, there would be a lot of false positives arising from compiler optimized code as well as correctly hand-optimized code.

Speaking of which, I was working with some codec from a vendor which was giving off these errors when ported to Linux and run under Valgrind. But the vendor convinced me that only several bits of the value being used actually came from uninitialized memory, and those bits were carefully avoided by the logic.. Only the good bits of the value were being used and Valgrind doesn't have the ability to track down to the individual bit. The uninitialized material came from reading a word past the end of a bit stream of encoded data, but the code knows how many bits are in the stream and will not use more bits than there actually are. Since the access beyond the end of the bit stream array does not cause any harm on the DSP architecture (there is no virtual memory after the array, no memory-mapped ports, and the address does not wrap) it is a valid optimization technique.

“未定义的行为”并没有多大意义，因为根据ISO C，简单地包含一个C标准中没有定义的头文件，或者调用一个程序本身或C标准中没有定义的函数，都是未定义行为的例子。未定义的行为并不意味着“没有被地球上的任何人定义”，而是“没有被ISO C标准定义”。当然，有时候未定义的行为是绝对没有人能定义的。

你写的:

我读过很多“任何事情都可能发生”，“市场细分可能是。 “最不坏的问题”，“你的硬盘可能会变成粉红色，独角兽也可能 在你的窗下唱歌，这是很好的，但真正的 危险吗?

这么说吧，给枪上膛。瞄准窗外，不要瞄准，然后开火。危险在哪里?

The issue is that you do not know. If your code overwrites something that crashes your program you are fine because it will stop it into a defined state. However if it does not crash then the issues start to arise. Which resources are under control of your program and what might it do to them? I know at least one major issue that was caused by such an overflow. The issue was in a seemingly meaningless statistics function that messed up some unrelated conversion table for a production database. The result was some very expensive cleanup afterwards. Actually it would have been much cheaper and easier to handle if this issue would have formatted the hard disks ... with other words: pink unicorns might be your least problem.

认为操作系统会保护你的想法是乐观的。如果可能，尽量避免越界写作。

Objective-C中的nsarray被分配一个特定的内存块。超过数组的边界意味着您将访问没有分配给数组的内存。这意味着:

This memory can have any value. There's no way of knowing if the data is valid based on your data type. This memory may contain sensitive information such as private keys or other user credentials. The memory address may be invalid or protected. The memory can have a changing value because it's being accessed by another program or thread. Other things use memory address space, such as memory-mapped ports. Writing data to unknown memory address can crash your program, overwrite OS memory space, and generally cause the sun to implode.

从程序的角度来看，您总是想知道代码何时超出了数组的边界。这可能导致返回未知值，导致应用程序崩溃或提供无效数据。

在测试代码时，您可能想尝试使用Valgrind中的memcheck工具——它不会捕获堆栈框架内的单个数组边界违规，但它应该捕获许多其他类型的内存问题，包括那些会导致单个函数范围之外的微妙、更广泛的问题的问题。

摘自手册:

Memcheck is a memory error detector. It can detect the following problems that are common in C and C++ programs. Accessing memory you shouldn't, e.g. overrunning and underrunning heap blocks, overrunning the top of the stack, and accessing memory after it has been freed. Using undefined values, i.e. values that have not been initialised, or that have been derived from other undefined values. Incorrect freeing of heap memory, such as double-freeing heap blocks, or mismatched use of malloc/new/new[] versus free/delete/delete[] Overlapping src and dst pointers in memcpy and related functions. Memory leaks.

ETA:不过，正如卡兹的回答所说，它不是万能的，并且并不总是提供最有帮助的输出，特别是当您使用令人兴奋的访问模式时。