内存越界，为什么会崩溃

内存越界，为什么会崩溃

越界操作引起的崩溃根源一般是下面两种情况
1.权限问题 – 访问了没有相应访问权限的地址.一般读越界引起崩溃都是这种. 多数写越界也会直接或间接引起这种问题.
2.代码执行出错 – 执行了非法的代码或是由数据错误引起的代码执行异常. 这种错误多由写越界引起.比如写坏了栈导致执行的非法代码,读取错误数据. 写坏了堆引起堆管理代码执行异常等等.

越界就好比踏进了地雷区。很可能生还，也很可能碰到各种雷！！

“内存越界访问有两种：一种是读越界，即读了不属于自己的数据，如果所读的内存地址
是无效的，程度立刻就崩溃了。如果所读内存地址是有效的，在读的时候不会出问题，但由
于读到的数据是随机的，它会产生不可预料的后果。另外一种是写越界，又叫缓冲区溢出。
它会产生不可预料的后果，比如把程序返回地址改掉了，使函数返回时跳到未知内存，导致崩溃。

free的时候会做完整性检查

野指针，也就是指向不可用内存区域的指针。通常对这种指针进行操作的话，将会使程序发生不可预知的错误。
“野指针”不是NULL指针，是指向“垃圾”内存的指针。人们一般不会错用NULL指针，因为用if语句很容易判断。但是“野指针”是很危险的，if语句对它不起作用。野指针的成因主要有两种：

一、指针变量没有被初始化。任何指针变量刚被创建时不会自动成为NULL指针，它的缺省值是随机的，它会乱指一气。所以，指针变量在创建的同时应当被初始化，要么将指针设置为NULL，要么让它指向合法的内存。

二、指针p被free或者delete之后，没有置为NULL，让人误以为p是个合法的指针。别看free和delete的名字恶狠狠的（尤其是delete），它们只是把指针所指的内存给释放掉，但并没有把指针本身干掉。通常会用语句if (p != NULL)进行防错处理。很遗憾，此时if语句起不到防错作用，因为即便p不是NULL指针，它也不指向合法的内存块。例：

另外一个要注意的问题：不要返回指向栈内存的指针或引用，因为栈内存在函数结束时会被释放。
指针是个很强大的工具，可是正因为它太强大，所以要操作它不是件易事。操作不当造成的野指针，甚至会引起系统死机等比较严重的后果。 　如果程序定义了一个指针，就必须要立即让它指向一个我们设定的空间或者把它设为NULL，如果没有这么做，那么这个指针里的内容是不可预知的，即不知道它指向内存中的哪个空间（即野指针），它有可能指向的是一个空白的内存区域，可能指向的是已经受保护的区域，甚至可能指向系统的关键内存，如果是那样就糟了，也许我们后面不小心对指针进行操作就有可能让系统出现紊乱，死机了。所以我们必须设定一个空间让指针指向它，或者把指针设为NULL，这是怎么样的一个原理呢，如果是建立一个与指针相同类型的空间，实际上是在内存中的空白区域中开辟了这么一个受保护的内存空间，然后用指针来指向它，那么指针里的地址就是这个受保护空间的地址了，而不是不可预知的啦，然后我们就可以通过指针对这个空间进行相应的操作了；如果我们把指针设为NULL，我们在头文件定义中的 #define NULL 0 可以知道，其实NULL就是表示0，那么我们让指针＝NULL，实际上就是让指针＝0，如此，指针里的地址（机器数）就被初始化为0了，而内存中地址为0 的内存空间……不用多说也能想象吧，这个地址是特定的，那么也就不是不可预知的在内存中乱指一气的野指针了。 　　还应该注意的是，free和delete只是把指针所指的内存给释放掉，但并没有把指针本身干掉。指针p被free以后其地址仍然不变（非NULL），只是该地址对应的内存是垃圾，p成了“野指针”。如果此时不把p设置为NULL，会让人误以为p是个合法的指针。用free或delete释放了内存之后，就应立即将指针设置为NULL，防止产生“野指针”。内存被释放了，并不表示指针会消亡或者成了NULL指针。（而且，指针消亡了，也并不表示它所指的内存会被自动释放。） 　　最后，总结一下野指针的的成因吧： 1、指针变量没有被初始化。任何指针变量刚被创建时不会自动成为NULL指针，它的默认值是随机的，它会乱指一气。 2、指针p被free或者delete之后，没有置为NULL，让人误以为p是个合法的指针。 3、指针操作超越了变量的作用范围。这种情况让人防不胜防。

https://blog.csdn.net/tongxinxiao/article/details/8502304

https://www.cnblogs.com/clover-toeic/p/3816644.html

#include <stdio.h>
int main()
{
    
}

全局变量和局部变量初始化与不初始化的区别
即int x 和 int x=0的区别。

int x =0; 跟 int x; 的效果看起来是一样的。但其实这里面的差别很大，强烈建议大家所有的全局变量都要初始化，他们的主要差别如下：

编译器在编译的时候针对这两种情况会产生两种符号放在目标文件的符号表中，对于初始化的，叫强符号，未初始化的，叫弱符号。连接器在连接目标文件的时候，如果遇到两个重名符号，会有以下处理规
则：
1、如果有多个重名的强符号，则报错。
2、如果有一个强符号，多个弱符号，则以强符号为准。
3、如果没有强符号，但有多个重名的弱符号，则任选一个弱符号。

例：

#include "stdafx.h"
int i;
int main(int argc, char* argv[])
{
 printf(" i = %d\n",i);
 int j;
 printf(" j %d\n",j);
 return 0;
}

在Debug版下，i输出是0，j输出是-858993460，也就是0xCCCCCCCC。
至于为什么是这个值，有网友给出这个解释。（设计成0xcccccccc是有特殊用意的……这个好像叫做Poison，未初始化的Pointer去取值的话会出错。肯定有人问为什么不弄成0x00000000，因为空指针是指针的有效状态，可能会误导人，而0xCCCCCCCC在Windows下永远不可能是一个指针的有效状态（不是NULL，不指向一个对象，不指向一堆对象紧接之后的区域），这就是在模拟野指针……）

值得注意的是，同样的代码在Release版下，这段代码中未被初始化的变量最后打印出来的可能都是0。也有强大的网友给出解释。（重点在于vc的一个功能：Catch release-build errors in debug build用/GZ编译开关打开。debug版这个开关是开的，release版是关的（为了效率）。这个开关说白了就是把所有动态局部变量初始化成0xcccccccc，把所有动态堆变量初始化成0xcdcdcdcd。很多新手会忘记初始化这些本来应该初始化的变量（尤其是new出来的变量），有时他们会假定这些变量应该是0，这样就可能出现在release版正常而debug版不正常的程序，因为release版至少局部变量的初始值很可能就是0，而有时他们又会假定或者期望这些变量不是0，这样就带了一个最难发现的bug）

切记 无论什么变量，记得初始化！！！！