关于gcc和vs的一点小看法和疑问

zhaohongjian000

测试楼主代码，Mingw下错误代码死循环。

wkq5325

回复 11# zhaohongjian000

你把那个注释的一行去掉试试，我说了注释的一行去掉在我的环境下可以跑起来，没说一定在别的环境跑起来。

zhangsuozhu

malloc申请到的内存是没有保证被初始化为0的，当然也有一定机会是0.
你每次都可以，很大程度是因 ...
hellioncu 发表于 2010-08-18 12:03

    他说的是对的! 这个真和编译器不相干

chinesedragon

我的基础不行

OwnWaterloo

回复 1# wkq5325

这种问题， 研究可以， 但不能依赖……

malloc不是魔法， 最终也是向OS申请内存。
而OS申请的内存， 可能就是填0的， 理由如下：

比如window下， VirtualAlloc分配出来的都是全0。
mmap, sbrk不太了解。

抛开具体的OS， 从security来说。
OS也很有可能将新分配的物理页面填0， 以避免bad gay通过取巧手段获得其他进程的内存中的机密数据。


综上， OS给malloc的内存很可能是全0。
再加上存在一些内存分配算法， 仅改写这些新获得内存中的必要部分。
最终分配给用户的时候， 就是一些全0的block。


而vs的crt是会填写一些magic value， 好像是0xfd。

lz的gcc的libc可能就是完全不改写那些新获得内存的， 保持0不变。
—— 如果真是这样， 那重启进程多少次应该都是相同的结果。
可以改写程序， 先分配一个链表， 填一些值。 释放后再分配， 可能就不是全0了（也不能保证不是）。

还是那句话， 这些问题可以研究， 但最终写代码的时候， 没有特殊情况（比如连一个赋值都忍受不了） 不应该依赖这种行为。
实在需要大块的全0 block， 可以考虑直接向OS要， 或者用calloc。
有些calloc的实现是会利用OS的这个特性来优化的。

xiaoqing87316

无论怎样吧，我觉得有一个良好的编程习惯倒是最主要的。那样的话，就可以忽略很多有关平台的问题了。

wkq5325

回复 15# OwnWaterloo
赞同，当时也就是觉得有点意思。谢谢

chinesedragon

这个是和编译器有关？