Am Fre, 2003-01-31 um 22.37 schrieb Alexandre Julliard: > I think it's cleaner to return a dup of the fd instead of relying on > the fact that the fd is cached internally. This may not always be the > case, and it's better to risk an fd leak than to risk invalidating the > cached value in case someone closes the fd when they shouldn't.
I see your point, but I don't see the risk you're talking about. The new coding rule (after removing the dup) is very simple: ** Never close() a Unix fd that you haven't open()d or dup()d ** yourself. Actually, one could formulate it more clearly: ** Never call close() unless you really know what you're doing. That is easy to understand for everybody, I reckon. I think it is much more likely that a programmer forgets a close() call than that he erroneously writes one, especially because it is pretty hard to even find the hidden dup() that creates all these fd's. When I was new to wine I guess it took me least a week to understand why the close() calls appeared everywhere. The current rule is much more complex. Especially with asynchronous IO it becomes *very* hard to track the open fd's. Please rethink your position on this subject. Martin -- Martin Wilck Phone: +49 5251 8 15113 Fujitsu Siemens Computers Fax: +49 5251 8 20409 Heinz-Nixdorf-Ring 1 mailto:[EMAIL PROTECTED] D-33106 Paderborn http://www.fujitsu-siemens.com/primergy
