考大家一个问题，fclose要不要判断返回值？？？？

flw

原帖由 yecheng_110 于 2008-1-24 15:18 发表

他用虚拟机 分了3.2G 用光了

真实产品也会在 3.2G 的硬盘上运行吗？

yecheng_110

原帖由 flw 于 2008-1-24 15:19 发表

真实产品也会在 3.2G 的硬盘上运行吗？

320G也会用光的吧
何况公司的开发环境是虚拟机

[ 本帖最后由 yecheng_110 于 2008-1-24 15:25 编辑 ]

思一克

FH说的意思是:

malloc分配的不是物理的内存. 所以,一般malloc总会成功,即使另一个进程已经将物理内存基本耗尽了.
只有自己有内存泄露才会不成功.

事实上, 如果不是DAEMAON程序(是运行一次就退出的), 而且申请的总内存量是有限的(比如,一共小于1G), 那么判断malloc基本没有用.
也不需要free.

原帖由 FH 于 2004-2-27 10:59 发表
我的意思是说malloc的大小不取决于物理或虚拟内存，取决于堆的大小。

我同意就这个问题到此为止，毕竟每个人所处的阶段和层次不一样，玩5年的人和玩15年的人如果能看法一致，说明5年的那位是天才，15年的那位 ...

flw

原帖由 yecheng_110 于 2008-1-24 15:24 发表

320G也会用光的吧

这就是架构问题了，不是程序问题了。

flw2

看了那个fclose->write失败的帖子，就觉得严格的话应该关闭了，否则，我们就做了一个这样的假设： 磁盘不会满
实际上很多时候都不会发生，就好比fprintf的返回值也需要检查一样，有谁检查吗？

malloc就像思版主说的，基本上肯定成功，如果malloc失败，只有两种可能
1. 地址空间耗尽，通常是daemon发生内存泄露
2 .malloc一个超级大的

所以在linux中，非daemon非太大的长度 malloc是绝对不会失败的

思一克

看close()的说明

Not checking the return value of close is a common but nevertheless serious programming error.   It  is  quite
       possible that errors on a previous write(2) operation are first reported at the final close.  Not checking the
       return value when closing the file may lead to silent loss of data.  This can especially be observed with  NFS
       and with disk quota.

       A  successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers
       writes. It is not common for a filesystem to flush the buffers when the stream is closed. If you  need  to  be
       sure that the data is physically stored use fsync(2).

Sorehead

malloc俺检查，fclose从不检查。
发贴完毕。

weigongwan

原帖由 flw 于 2/27/2004 11:24 发表
检查 malloc 是必要的。

检查 fclose 纯属吹毛求疵。
如果怕写不成功的话，
fflush 好了。

我非常赞成“效率”这个说法。
假如说，fclose 你检查到失败了怎么办？
是不是得提示一句话？
或者写日志文 ...

偶像派说出来的话就是不一样，俺也是只检查malloc，从来就没有管过fclose。永远支持flw……

想飞的蜗牛

看了这次讨论和昨天yxping关于缓冲区的讨论
我觉得以后还是不用fwrite了......

woyaya

原帖由 FH 于 2004-2-26 17:08 发表
malloc是在堆里分配空间的，你的堆有多大？malloc分配的不是物理内存，更不是交换区，基本概念先要搞懂！

至于什么深层返回的问题，我建议各层有各层的逻辑，你出现错误时只关闭本层的文件，并给上层一个标志 ...

顶这个