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? 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. If, instead, you mean "use close on p itself", as per: > *************** > *** 613,617 **** > return-an-error; > /* XXX should check return from fclose() too */ > #endif > ! (void)fclose((FILE *)p); > } > --- 621,626 ---- > return-an-error; > /* XXX should check return from fclose() too */ > #endif > ! if (not_filep) close((int)p); > ! else (void)fclose((FILE *)p); > } then "close((int)p)" is wrong - at least on UNIX, "p" is a pointer *even if it's "stdout"*, so you can't just cast it to an integer and hand it to "close()" - "close()" will just reject it and do nothing, so that's equivalent to using neither "fclose()" *nor* "close()" if p == stdout. 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. - 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
