Hi Guy, Guy Harris wrote: > > On Tue, Mar 12, 2002 at 04:53:30PM +0100, Pierre-Yves Bonnetain wrote: > > The problem seems to lie in savefile::dump_close, which always uses > > fclose to close a dump file, whereas it should (ihmo) use close if dump_open > > worked on stdout > > Why?
The killing question (it's better in french : la question qui tue, meaning that question is the killing stroke). You are right, of course. I jumped a little too fast on the wrong conclusion. After one day on this problem, I got trigger happy. Serves me right. > If you mean "use close on fileno(p)", then the only difference between > using "close()" and "fclose()" on stdout is that if you use "fclose()", > it closes file descriptor 1 *and* frees up and invalidates the "stdout" > FILE *, while if you use "close()", it merely closes file descriptor 1. I am using a Perl interface to drive pcap analysis, and in my perl debugger I was printing fileno(stdout), and mistakenly took it as stdout when going to libpcap source code. The fact that my "patch" solved my problem did convince me I had the right answer. But I just close "the wrong thing". > Why are you having a problem with the close? Is your application trying > to write more than one capture stream, in sequence, to the standard > output? If so, then the correct fix would either be to do nothing, or > do an "fflush()", in "pcap_close()" if p == stdout. Yes. My dump files are huge (several Gbytes), so I want to split them into manageable parts. I open a capture file (compressed), and spit data sequentially into (on-the-fly-compressed) output files. Playing with stdout all the time. Currently I just rolled out my incorrect patch and do nothing in dump_close if p == stdout. It works :-) Thanks for the correction. -- Pierre-Yves Bonnetain Consultant S�curit� -- B&A Consultants T�l +33 (0) 563 277 241 -- Fax +33 (0) 563 277 245 - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
