不检查边界可能会导致严重的副作用，包括安全漏洞。其中最糟糕的是任意执行代码。在经典示例中:如果您有一个固定大小的数组，并使用strcpy()在那里放置一个用户提供的字符串，用户可以给您一个字符串，该字符串会溢出缓冲区并覆盖其他内存位置，包括函数结束时CPU应该返回的代码地址。

这意味着你的用户可以向你发送一个字符串，这将导致你的程序实质上调用exec(“/bin/sh”)，这将把它变成shell，在你的系统上执行任何他想要的东西，包括收集你的所有数据，并将你的机器变成僵尸网络节点。

关于如何做到这一点的详细信息，请参见Smashing The Stack For Fun And Profit。

一般来说，现在的操作系统(流行的操作系统)使用虚拟内存管理器在受保护的内存区域中运行所有应用程序。事实证明，简单地读取或写入存在于已分配给进程的区域之外的REAL空间中的位置(就其本身而言)并不容易。

直接回答:

Reading will almost never directly damage another process, however it can indirectly damage a process if you happen to read a KEY value used to encrypt, decrypt, or validate a program / process. Reading out of bounds can have somewhat adverse / unexpected affects on your code if you are making decisions based on the data you are reading The only way your could really DAMAGE something by writing to a loaction accessible by a memory address is if that memory address that you are writing to is actually a hardware register (a location that actually is not for data storage but for controlling some piece of hardware) not a RAM location. In all fact, you still wont normally damage something unless you are writing some one time programmable location that is not re-writable (or something of that nature). Generally running from within the debugger runs the code in debug mode. Running in debug mode does TEND to (but not always) stop your code faster when you have done something considered out of practice or downright illegal. Never use macros, use data structures that already have array index bounds checking built in, etc....

ADDITIONAL I should add that the above information is really only for systems using an operating system with memory protection windows. If writing code for an embedded system or even a system utilizing an operating system (real-time or other) that does not have memory protection windows (or virtual addressed windows) that one should practice a lot more caution in reading and writing to memory. Also in these cases SAFE and SECURE coding practices should always be employed to avoid security issues.

你写的:

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

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

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.

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

二维或多维数组的考虑超出了其他答案中提到的那些。考虑以下函数:

char arr1[2][8];
char arr2[4];
int test1(int n)
{
  arr1[1][0] = 1;
  for (int i=0; i<n; i++) arr1[0][i] = arr2[i];      
  return arr1[1][0];
}
int test2(int ofs, int n)
{
  arr1[1][0] = 1;
  for (int i=0; i<n; i++) *(arr1[0]+i) = arr2[i];      
  return arr1[1][0];
}

The way gcc will processes the first function will not allow for the possibility that an attempt to write arr[0][i] might affect the value of arr[1][0], and the generated code is incapable of returning anything other than a hardcoded value of 1. Although the Standard defines the meaning of array[index] as precisely equivalent to (*((array)+(index))), gcc seems to interpret the notion of array bounds and pointer decay differently in cases which involve using [] operator on values of array type, versus those which use explicit pointer arithmetic.

就ISO C标准(该语言的官方定义)而言，在其边界之外访问数组具有“未定义行为”。字面意思是:

行为，在使用不可移植或错误的程序构造或 错误的数据，本标准没有规定 需求

一个非规范性的注释对此进行了扩展:

可能的未定义行为包括忽略情况 翻译过程中的行为完全无法预测结果 或以文件化的方式执行程序的特点 环境(有或没有发出诊断消息)，到 终止翻译或执行(通过发出 诊断消息)。

这就是理论。现实是什么?

在“最佳”情况下，您将访问一些内存，这些内存要么属于当前运行的程序(这可能导致您的程序行为不正常)，要么不属于当前运行的程序(这可能导致您的程序因分段错误而崩溃)。或者你可能会尝试写入程序拥有的内存，但它被标记为只读;这也可能导致您的程序崩溃。

That's assuming your program is running under an operating system that attempts to protect concurrently running processes from each other. If your code is running on the "bare metal", say if it's part of an OS kernel or an embedded system, then there is no such protection; your misbehaving code is what was supposed to provide that protection. In that case, the possibilities for damage are considerably greater, including, in some cases, physical damage to the hardware (or to things or people nearby).

即使在受保护的操作系统环境中，保护也不总是100%。例如，有些操作系统错误允许非特权程序获得根(管理)访问权限。即使使用普通用户权限，出现故障的程序也会消耗过多的资源(CPU、内存、磁盘)，可能导致整个系统瘫痪。许多恶意软件(病毒等)利用缓冲区溢出来获得对系统的未经授权的访问。

(一个历史上的例子:我听说在一些具有核心内存的旧系统上，在一个紧密循环中重复访问单个内存位置可能会导致内存块融化。其他的可能性包括损坏CRT显示器，以驱动器柜的谐波频率移动磁盘驱动器的读写头，导致它走过桌子，掉到地板上。)

而且还要担心天网。

底线是这样的:如果你可以编写一个程序故意做一些不好的事情，那么至少在理论上，一个有bug的程序可能会意外地做同样的事情。

实际上，在MacOS X系统上运行的有bug的程序不太可能出现比崩溃更严重的情况。但是完全阻止有bug的代码做一些非常糟糕的事情是不可能的。

如果您曾经做过系统级编程或嵌入式系统编程，如果您随机写入内存位置，可能会发生非常糟糕的事情。旧系统和许多微控制器使用内存映射IO，因此写入映射到外设寄存器的内存位置可能会造成严重破坏，特别是如果它是异步完成的。

一个例子是编程闪存。内存芯片上的编程模式是通过将特定的值序列写入芯片地址范围内的特定位置来实现的。如果在此期间另一个进程写入芯片中的任何其他位置，则会导致编程周期失败。

在某些情况下，硬件会将地址环绕起来(地址中最重要的位/字节会被忽略)，因此写入超出物理地址空间末端的地址实际上会导致数据在中间写入。

最后，像MC68000这样的老cpu可能会锁定到只有硬件重置才能让它们重新工作的地步。我已经几十年没有使用它们了，但我相信当它在试图处理异常时遇到总线错误(不存在内存)时，它会简单地停止，直到断言硬件重置。

我最大的建议是为一个产品做一个明显的宣传，但我个人对此没有兴趣，我也不以任何方式与他们联系——但基于几十年的C编程和嵌入式系统，可靠性是至关重要的，Gimpel的PC Lint不仅可以检测这类错误，还可以通过不断地唠叨你的坏习惯，让你成为更好的C/ c++程序员。

我还建议你阅读MISRA C编码标准，如果你能从别人那里得到一份的话。我没有看到最近的任何一个，但在过去的日子里，他们给了一个很好的解释，为什么你应该/不应该做他们覆盖的事情。

我不知道你的情况，但当我第二次或第三次从任何应用程序中得到一个coredump或挂起时，我对任何公司的看法都会下降一半。第四次或第五次，不管是什么包装都变成了架子，我用一根木桩穿过包装/光盘的中心，只是为了确保它永远不会回来缠着我。