发现一个C语言BUG，定义int变量时靠近char的变量会变成0，是什么原因
头条现在好多不明不白的问题，半截子话让大家去猜。
我估计是int型变量在char数组后面定义的，然后用指针给p赋值时下标越界了。
char arr[3] = {0};
int a = 10;
char* p = arr;
*(p+3) = 0;
int bb = 3;
开始时内存中数据可能是
00 00 00 0A 00 00 00，
其中前3字节是arr，后4字节是a
在int bb处加断点，运行到断点处再看就变成了
00 00 00 00 00 00 00
指针不会判断是否越界的
程序员最常见到的口头禅是，“这个问题好奇怪”，“在我机器上好好的！！！” ....
所以，题主的问题根本就不是一个问题。遇到类似问题，应该先从自己代码本书找原因，而不是去怀疑语言或者编译器。原因很简单，这些东东都几十年了，要是有这么简单的Bug早就被发现了。
由于题主没有贴出自己的代码，因此没办法帮题主分析问题在哪，但是在实际开发中有很多原因会导致题主所说的问题。我们举几个例子。
局部变量与全局变量
局部变量默认是不会被初始化的，因此当访问局部变量的时候其值是一个随机值，可能是0，也可能是其它值。
但是全局变量如果没有被显示初始化的情况下，是一定被初始化为0的。因此如果你得代码是这样的，那么itest的输出值一定是0，而test则不一定。所以你觉得int变量在靠近char的时候会变成0，其实没有因果关系。
内存访问越界
另外一种情况是访问越界的问题，如果你char类型的变量存在访问越界的问题，可能会把邻居的变量给覆盖了，从而导致认为的结果。同样，我们来看一个例子。
如图所示，图中的gtest变量，你本来以为是9的，但实际打印的时候却是0.这就是因为在对ctest清零的时候越界造成的。
类似的问题还很多，当我们遇到问题的时候还是要尽量从代码本身找问题，这样更容易一些。至于编译器，肯定是有Bug的，估计我们遇到的可能性不会太大。
不可能有这种BUG，C语言出现多少年了，这种显而易见极易复现的BUG不可能等到现在让你一个初学者发现。作为一种机器成熟大量实用的语言，不能说现在毫无bug了。。有BUG也是那种极难发现和复现，极难碰到的场景下才有。被初学者发现的概率为0！
很多开发人员都有过这样的经历，当被一些稀奇古怪的问题折腾得精疲力尽时，就开始怀疑开发环境的问题，怀疑编译器的问题，怀疑运行时的问题，甚至开始怀疑人生[捂脸]
没错，我也遇到过，不过最终发现，开发环境、编译器和运行时出 bug 的概率太低了，比买双色球中奖的概率还低。问题还是自己的问题，只是定位问题的过程比较曲折而已。
题主所说的问题大概有这两种情况:
1，定义变量没赋初值，这种情况下变量值是不确定的，可以是任何值，也可能是 0。
2，变量在某个时候被其他地方修改了，如通过指针的方式修改，或调用函数时引用传参并被修改。 这两种方式在代码层面可能不太直观，容易被忽略。
所以题主可以试下按照我说的情况加以分析定位问题。
keil开发arm内核aducm360，程序使用优化optimization为level1时，程序就会有问题。完全不优化level0没有问题。一查反汇编，真有问题。所以也不是编译程序一定没问题。当然自己有问题的时候多得多。但对我来说，不管是什么问题，都是查查查，而不是躲避。keil在一星期中查出3个问题。除了上面，还有软件仿真计时不准，统计软件命令数错，使得命令覆盖率达不到100%。也是有点吃惊。类似查到的还有，在半双工的串口发送时，可能会有接收字符。也可能是在发送时，先要清输入，如读一下输入缓冲区。感觉能查问题才是真本领。串口的问题最难查，可能好几小时才发生一次。像上面这种静态问题，应该很好查。把程序打出来，可以很快查出来的。
