Chinaunix

标题: 考大家一个问题,fclose要不要判断返回值???? [打印本页]

作者: ldap    时间: 2004-02-26 15:42
标题: 考大家一个问题,fclose要不要判断返回值????
考大家一个问题,fclose要不要判断返回值????
作者: google2002    时间: 2004-02-26 15:50
标题: 考大家一个问题,fclose要不要判断返回值????
老实说FCLOSE和MALLOC我都不检查,
如果这些函数出问题了表明系统也就要完蛋了,
这时候你除了ABORT还能做什么?
[quote]原帖由 "ldap"]考大家一个问题,fclose要不要判断返回值????[/quote 发表:

作者: Wangwen    时间: 2004-02-26 15:54
标题: 考大家一个问题,fclose要不要判断返回值????
不要
作者: ldap    时间: 2004-02-26 15:58
标题: 考大家一个问题,fclose要不要判断返回值????
[quote]原帖由 "google2002"][/quote 发表:



此话差已,对于malloc,如果真的失败了的话,系统是也做不了什么了,但是如果不处理的话,可能会导致更为严重的错误,哪怕让程序安全退出也是好的啊!举个例子,如果数据库管理系统(DBMS)中malloc出错了,而你的程序继续做下去,很有可能导致段错误,当然如果程序写的好的,捕捉到11号信号后做一下清除处理,然后退出;写的不好的,直接退出了,谁去回滚事务等等。就算是捕捉到信号后做处理,在日志里留下个段错误记录好像也不太好看。


对于fclose则确实有检查返回值的必要!
作者: FH    时间: 2004-02-26 16:01
标题: 考大家一个问题,fclose要不要判断返回值????
fclose有返回码,但一般不检查,除非特殊情况。

至于malloc不检查,我不赞同,我好像知道为什么Windows总死机了……
作者: forest077    时间: 2004-02-26 16:03
标题: 考大家一个问题,fclose要不要判断返回值????
fclose我从来不检查。查了一下man手册,说出错的时候返回EOF,比如说这个文件尚未打开。不过我平常的经验发现文件尚未打开而关闭一个空的文件指针会core dump。
作者: forest077    时间: 2004-02-26 16:07
标题: 考大家一个问题,fclose要不要判断返回值????
malloc我认为应该检查,至少有一种情况是有很大可能会发生,就是内存空间不够的问题,此时malloc肯定会失败。
作者: ldap    时间: 2004-02-26 16:12
标题: 考大家一个问题,fclose要不要判断返回值????
要最求C代码的高质量!

我不赞成使用f系列函数。
第一、这些函数是stdio的例程,通过系统调用操作文件会得到更大的控制能力。
第二、这些函数在系统调用之上的包装在不同的Unix系统上表现是不一样的。
第三、这些函数调用在内部有一些限制,比如于小于256的文件描述字对应。


对于fclose检查返回值的问题是必须的。

比如磁盘空间没有了,这是你调用了一下fwrite,它很可能会成功返回,因为fwrite只是把数据写到缓冲区中,当你调用fclose的时候,就会不成功,因为它要刷磁盘的。
作者: google2002    时间: 2004-02-26 16:17
标题: 考大家一个问题,fclose要不要判断返回值????
1。按照目前的操作系统的SWAP机制来说是不可能返回MALLOC失败的,
哪位能告诉我他试过MALLOC失败的,当然你申请分配一个1T的内存空间这种情况不算
2。万一真的返回MALLOC失败,你以为你还能让程序安全退出吗?
至于FCLOSE我觉得绝大多数情况下是没必要的
这个是取决与你开发的效率和安全性之间的比较
原帖由 "ldap" 发表:



此话差已,对于malloc,如果真的失败了的话,系统是也做不了什么了,但是如果不处理的话,可能会导致更为严重的错误,哪怕让程序安全退出也是好的啊!举个例子,如果数据库管理系统(DBMS)中malloc出错了,而?.........

作者: ldap    时间: 2004-02-26 16:26
标题: 考大家一个问题,fclose要不要判断返回值????
开发效率与安全性的比较。

这是我非常不能赞成的。其实想想,编码过程才占整个软件开发过程很小的一部分时间的。这是一种习惯,其实并不会浪费时间的。我现在在看一本书《UNix高级编程》,不是steven那本,是人民邮电出的,Warren W.Gay写的,整本书里都有很多平时不注意的地方,我觉得很好。大家可以看看。


    做操作系统的不要相信硬件是完美的
    做应用程序的也不要相信操作系统是完美的
作者: google2002    时间: 2004-02-26 16:34
标题: 考大家一个问题,fclose要不要判断返回值????
呵呵,当你写的多UNIX服务器你就会知道什么时候要检查什么时候不需要了
如果每个地方都检查你的代码在非常复杂的逻辑处理模块是很难返回到上一层,特别是你调用之前就占用了锁之类的资源的时候。

另外建议你别用fopen/fclose的,
我只用open/close,而且open之后就不释放直到程序退出才释放的

如果写嵌入式系统我会考虑这些返回值,如果是普通的UNIX服务器,我不会检查
原帖由 "ldap" 发表:
开发效率与安全性的比较。

这是我非常不能赞成的。其实想想,编码过程才占整个软件开发过程很小的一部分时间的。这是一种习惯,其实并不会浪费时间的。我现在在看一本书《UNix高级编程》,不是steven那本,是人民..........

作者: ldap    时间: 2004-02-26 16:49
标题: 考大家一个问题,fclose要不要判断返回值????
看看postgres源代码就知道怎么会跳到上层,甚至上几层。这是仁者见仁智者见智的事情了,不讨论也罢。
作者: google2002    时间: 2004-02-26 16:55
标题: 考大家一个问题,fclose要不要判断返回值????
postgres作为一个数据库底层存储,写文件是他最重要的功能,自然要检查fclose;
但是普通的UNIX服务器用FOPEN通常都是读写一些配置或者日志,
两者的重要性根本不同。
这个就是我说的开发效率和需要的安全性的对比!
[quote]原帖由 "ldap"]看看postgres源代码就知道怎么会跳到上层,甚至上几层。这是仁者见仁智者见智的事情了,不讨论也罢。[/quote 发表:

作者: FH    时间: 2004-02-26 17:08
标题: 考大家一个问题,fclose要不要判断返回值????
malloc是在堆里分配空间的,你的堆有多大?malloc分配的不是物理内存,更不是交换区,基本概念先要搞懂!

至于什么深层返回的问题,我建议各层有各层的逻辑,你出现错误时只关闭本层的文件,并给上层一个标志出错的返回码就可以了,上层的文件归上层自己关闭。

难怪现在有这么多垃圾程序,还自以为高深呢,不过是把简单问题自己给复杂化了而已!
作者: ldap    时间: 2004-02-26 17:12
标题: 考大家一个问题,fclose要不要判断返回值????
你如果这么说,我是可以理解的。

在postgres底层存储的部分,没有用fopen系列函数的,道理你肯定明白,你也赞成。

OK,这篇帖子到此结束,我只是举个例子,至于如何使用,还是要看具体的环境。

当然对于大家研究而言,我想我们还是要求精益求精,对吧。
作者: google2002    时间: 2004-02-26 17:19
标题: 考大家一个问题,fclose要不要判断返回值????
我说的是虚拟内存
你还挺有意思的,如果堆不在不是物理内存也不在交换区,那是哪里出来的?
莫非是天上掉下来的?

至于深层返回错误代码之类的我就不讨论了,只要你想实现都可以做,重复多次这是一个开发效率的问题

再说服务器程序写的好不好不是说一个检查系统调用决定的,
如果还对这个死缠烂打,只能说明还在UNIX服务器的初级程序员阶段

原帖由 "FH" 发表:
malloc是在堆里分配空间的,你的堆有多大?malloc分配的不是物理内存,更不是交换区,基本概念先要搞懂!

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

作者: seaglexiao    时间: 2004-02-26 17:46
标题: 考大家一个问题,fclose要不要判断返回值????
如果你这样做出问题了表明你是错的,
如果你这样做媒出问题去不见得你是对的。
呵呵
作者: weizzil_chinaun    时间: 2004-02-26 17:57
提示: 作者被禁止或删除 内容自动屏蔽
作者: a_beginner    时间: 2004-02-26 23:01
提示: 作者被禁止或删除 内容自动屏蔽
作者: FH    时间: 2004-02-27 10:59
标题: 考大家一个问题,fclose要不要判断返回值????
我的意思是说malloc的大小不取决于物理或虚拟内存,取决于堆的大小。

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

俺是15年的饭桶。
作者: flw    时间: 2004-02-27 11:24
标题: 考大家一个问题,fclose要不要判断返回值????
检查 malloc 是必要的。

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

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

但是如果你写日志文件又错了怎么办?
如果 sprintf 出错了怎么办?
如果 printf、fprintf 出错了怎么办?

如果什么都得检查,
那么你的程序到底是在干什么?

这就好比一个人,得了“心理强迫症”,
掏东西的时候老怕把钱夹子掉出来,
开门的时候怕把细菌沾手上,
尽管偶尔看看钱夹子有没有掉出来、
开门的时候手上是不是脏了、是不是需要洗手
是一个好习惯,但是如果你老是这样,
你将除了一事无成之外,
只怕精神也要崩溃。

作者: flw    时间: 2004-02-27 11:33
标题: 考大家一个问题,fclose要不要判断返回值????
说得再细一些,

钱夹子有时候会掉。
就好比 fclose 有时候会失败。

所以有时候,在有些场合,你可能需要看一下钱夹子有没有掉。
同样,如果你不嫌麻烦的话,偶尔检查一下 fclose 的返回值本也无可厚非。

但是,如果你老是看你的钱夹子,
就像你总是检查 fclose 一样,
你最终会精神分裂。
作者: yyl66    时间: 2004-02-27 12:35
标题: 考大家一个问题,fclose要不要判断返回值????
up
作者: quence    时间: 2004-02-27 12:47
标题: 考大家一个问题,fclose要不要判断返回值????
俺的建议是:
1)
只有一些交互信息,比如输出一些信息,写入一些日志,
才用stdio.
2)
对于文件的关键操作,比如数据库文件的读写,直接
用系统调用。
作者: li2002    时间: 2004-02-27 15:38
标题: 考大家一个问题,fclose要不要判断返回值????
写底层系统应用的检查严格些是应该的,对于大多写普通程序的不必每个都检查,但需要有一个好习惯。这可能就是菜鸟和老鸟的区别吧^_^
作者: forest077    时间: 2004-02-27 17:24
标题: 考大家一个问题,fclose要不要判断返回值????
开始看到这个讨论,我也困惑了,到底是否应该检查?看了flw版主的高论后,我豁然开朗了,flw说的确实有道理,至少从我这里,我不再去想这种问题了。
作者: lenovo    时间: 2004-02-27 17:31
标题: 考大家一个问题,fclose要不要判断返回值????
呵呵,在此之前,我都不知道还需要检查
fclose的返回值。看应用在什么场合吧。
合适的才是最好的。
作者: yecheng_110    时间: 2008-01-24 15:12
原帖由 flw 于 2004-2-27 11:24 发表
检查 malloc 是必要的。

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

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

今天同事写一个文件的时候老是写不进去
检查fwrite是成功的
但是一直找不到原因
后来换成用open write的方式
在write的时候出错 磁盘满
fwrite是有缓冲的 所以磁盘满也不一定失败
但是fflush或者fclose就出错了
作者: flw    时间: 2008-01-24 15:15
原帖由 yecheng_110 于 2008-1-24 15:12 发表

今天同事写一个文件的时候老是写不进去
检查fwrite是成功的
但是一直找不到原因
后来换成用open write的方式
在write的时候出错 磁盘满
fwrite是有缓冲的 所以磁盘满也不一定失败
但是fflush或者fclos ...

也许应该想想,磁盘为什么会满?
作者: yecheng_110    时间: 2008-01-24 15:18
原帖由 flw 于 2008-1-24 15:15 发表

也许应该想想,磁盘为什么会满?

他用虚拟机 分了3.2G 用光了
要是检查一下返回值 打印一条出错信息 可能就不会浪费这么多时间了

[ 本帖最后由 yecheng_110 于 2008-1-24 15:21 编辑 ]
作者: flw    时间: 2008-01-24 15:19
原帖由 yecheng_110 于 2008-1-24 15:18 发表

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

真实产品也会在 3.2G 的硬盘上运行吗?
作者: yecheng_110    时间: 2008-01-24 15:24
原帖由 flw 于 2008-1-24 15:19 发表

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

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

[ 本帖最后由 yecheng_110 于 2008-1-24 15:25 编辑 ]
作者: 思一克    时间: 2008-01-24 15:26
FH说的意思是:

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

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



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

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

作者: flw    时间: 2008-01-24 15:50
原帖由 yecheng_110 于 2008-1-24 15:24 发表

320G也会用光的吧

这就是架构问题了,不是程序问题了。
作者: flw2    时间: 2008-01-24 16:08
看了那个fclose->write失败的帖子,就觉得严格的话应该关闭了,否则,我们就做了一个这样的假设: 磁盘不会满
实际上很多时候都不会发生,就好比fprintf的返回值也需要检查一样,有谁检查吗?

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

所以在linux中,非daemon非太大的长度 malloc是绝对不会失败的
作者: 思一克    时间: 2008-01-24 16:14
看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    时间: 2008-01-24 16:40
malloc俺检查,fclose从不检查。
发贴完毕。
作者: weigongwan    时间: 2008-01-24 17:11
原帖由 flw 于 2/27/2004 11:24 发表
检查 malloc 是必要的。

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

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


偶像派说出来的话就是不一样,俺也是只检查malloc,从来就没有管过fclose。永远支持flw……
作者: 想飞的蜗牛    时间: 2008-01-24 19:45
看了这次讨论和昨天yxping关于缓冲区的讨论
我觉得以后还是不用fwrite了......
作者: woyaya    时间: 2008-01-25 10:30
原帖由 FH 于 2004-2-26 17:08 发表
malloc是在堆里分配空间的,你的堆有多大?malloc分配的不是物理内存,更不是交换区,基本概念先要搞懂!

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



顶这个
作者: hqx8211    时间: 2008-01-25 13:44
标题: 回复 #28 yecheng_110 的帖子
突然发现这个哥们在2008-1-24 15:18  回复 2004-2-27 11:24 的帖子.....超级汗,从第多少页翻出来的.....
作者: yecheng_110    时间: 2008-01-25 13:55
原帖由 hqx8211 于 2008-1-25 13:44 发表
突然发现这个哥们在2008-1-24 15:18  回复 2004-2-27 11:24 的帖子.....超级汗,从第多少页翻出来的.....

哥们 灌水呀
版规里不是有提问先搜索的说明吗




欢迎光临 Chinaunix (http://bbs.chinaunix.net/) Powered by Discuz! X3.2