[Winpcap-users] pcap_fopen_offline not exported?

[Bryan Kadzban]

-----BEGIN PGP SIGNED MESSAGE-----
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
functions.

> 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 fine.

> 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.  ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIiyFPS5vET1Wea5wRAxKqAJ4pavkGgwZaxI2bmOafQ89x2k5AzgCggzVO
IkwoBahm6eF7/OiSPw+Fi1g=
=drRm
-----END PGP SIGNATURE-----