[Winpcap-users] pcap_fopen_offline not exported?

Okraszewski, Marcin Marcin.Okraszewski at pl.compuware.com
Mon Jul 28 13:45:20 GMT 2008

So I have it working now. I have slightly modified WinPcap to make the
API expose the pcap_fopen_offline():

In pcap.h I have added:
#define pcap_fopen_offline(f,b) \
        pcap_hopen_offline(_get_osfhandle(_fileno(f)), b)

pcap_t  *pcap_hopen_offline(intptr_t, char *);

Then in savefile.c:
pcap_t* pcap_hopen_offline(intptr_t osfd, char *errbuf) 
    int fd;
    FILE *file;
    fd = _open_osfhandle(osfd, _O_RDONLY);
    if ( fd < 0 ) {
        strerror_s(errbuf, PCAP_ERRBUF_SIZE, errno);
		return NULL;

    file = _fdopen(fd, "rb");
    if ( file == NULL ) {
        strerror_s(errbuf, PCAP_ERRBUF_SIZE, errno);
        return NULL;
    return pcap_fopen_offline(file, errbuf); 

And finally I have added the pcap_hopen_offline to exports in wpcap.def.

Thank you all for input in this matter. Is there any chance this kind of
solution to be included in WinPcap?


The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. 

Compuware sp. z o.o. (registration number KRS 595) is a company registered in Poland whose registered office is at Ul. Dmowskiego 12,80-264 Gdansk Rejestr handlowy KRS 0000000595 Sadu Rejonowego Gdansk-Polnoc w Gdansku VII Wydzial Gospodarczy Kapital zakladowy 1.140.000 zl oplacony gotowka; NIP: 584-20-88-050; REGON: 191352920 

From: winpcap-users-bounces at winpcap.org
[mailto:winpcap-users-bounces at winpcap.org] On Behalf Of Bryan Kadzban
Sent: Saturday, July 26, 2008 3:06 PM
To: winpcap-users at winpcap.org
Subject: Re: [Winpcap-users] pcap_fopen_offline not exported?

Hash: RIPEMD160

Fish wrote:
> But the point is, the exported function's prototype could include 
> either a regular file descriptions (int fd) or a Win32 HANDLE

HANDLE, yes.  File descriptor, no; an integer file descriptor is a CRT
library construction on win32 (likely an index into a table of HANDLEs,
possibly plus a few other things, that's private to the run-time
library), and therefore can't be passed from one CRT to another.  At
best, it'll return errors when you try to use it (it may also crash); at
worst, it'll perform operations on some completely unrelated file.

> but you must still be careful not to have two different modules
> reading/writing to the same CRT file.

Not just the same CRT file.  You can't use the HANDLE that you passed
in to _open_osfhandle() *at all*, according to the docs that Guy Harris
just posted.  Operations like changing the file pointer that's held in
that HANDLE will break the assumptions made by the CRT's file operation

> Now of course if both modules were instead always using the Win32 
> file HANDLES to do all their file accessing with (and NOT the C/C++ 
> Runtime handle), then again there would NOT be any problem.

I don't know that for sure.  If you opened a file twice, and got two
HANDLEs to it, then you would probably be correct.  If you opened the
file once, passed the HANDLE off to other code, and both pieces of code
used it (directly), I think the bits of code would probably step on each
other.  Because I believe the file pointer is held in the HANDLE -- at
least unless you're doing overlapped I/O.  That *might* be safe, because
the file position pointers are held in the OVERLAPPED struct.  But there
may be other bits of information that are held in the HANDLE that can't
be shared between two pieces of code.

But using DuplicateHandle (on a normal file, not a socket) should be

> The only time a problem comes into play is when two different C/C++ 
> Runtimes try accessing the same underlying Win32 File object at the 
> same time using their own CRT file descriptions or buffered FILE* 
> pointers. THAT is the only thing that is dangerous.

Not using overlapped I/O on a normal Win32 HANDLE is dangerous as well.
So is using the HANDLE at the same time as a FILE* or a file descriptor
that was opened from that HANDLE.  This is not an exhaustive list,
either; there may be other unsafe operations.

> But as long as only ONE module is ultimately responsible for doing 
> ALL of the read/writing, then there's nothing preventing you from 
> simply changing the prototype of the exported function's parameters 
> to use 'int fd' or HANDLE instead of the existing/dangerous FILE* 
> pointer.

HANDLE, yes.  'int fd', no; see the first paragraph.  ;-)
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

Winpcap-users mailing list
Winpcap-users at winpcap.org

More information about the Winpcap-users mailing list