[Winpcap-users] pcap_fopen_offline not exported?

[Fish]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Guy Harris wrote:

> On Jul 25, 2008, at 3:27 PM, Gianluca Varenni wrote:
> 
> > this could work as long as you can get a FILE* handle out
> > of a win32 HANDLE. I've never tried myself, it looks a bit
> > scary to me...
> 
> I don't know whether you can do so in one step, but the  
> _open_osfhandle() documentation seems to imply that you can
> get a C run-time library file descriptor give "an existing
> operating-system file handle" and the _fdopen() documentation
> indicates that you can get a FILE * from a C run-time library
> file descriptor.

Right!


> The knowledgebase article Q99173:
> 
> 	http://support.microsoft.com/kb/q99173/
> 
> also indicates that _open_osfhandle() can be used on a HANDLE,  
> although it also indicates that you shouldn't use the HANDLE
> directly   after that, as you might get it out of sync with the C
> run-time  
> library FD:
<snip>

Quite right. But you're not doing that, are you?


> (BTW, KB article 139801:
> 
> 	http://support.microsoft.com/kb/139801
> 
> seems to indicate that
> 
> 	1) you can get socket handles (although whether they're HANDLEs
> is another matter)
<snip>

Um, does open_offline need to support socket handles too? If so that
could be a problem. I hadn't considered that.

But the point is, the exported function's prototype could include
either a regular file descriptions (int fd) or a Win32 HANDLE that
the caller would presumably have already opened, and then WinPcap
could then safely read/write to/from the file for itself using its
own C++ Runtime (CRT) functions if it wanted.

... AS LONG AS ...

As long as the caller knows not to ALSO read/write to/from the file
in question at the same time.

That is to say, one module CAN open the file and then pass the opened
file handle across module (DLL) boundaries to another module
responsible for actually read/writing to the file, but you must still
be careful not to have two different modules reading/writing to the
same CRT file.

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.

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.

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.

If you do that though (pass the "file handle" as an 'int fd' or
HANDLE), then you're safe.

<shrug>

Just trying to help.

(and FWIW, we do it with our product (Hercules[1]) and it works just
fine)

- -- 
"Fish" (David B. Trout) - fish(at)infidels.org
Fight Spam! Join CAUCE! <http://www.cauce.org/>
(Any HTML email received will be deleted unread)
PGP key fingerprints:
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBSIqXHkj11/TE7j4qEQKjUACffyaifUhWkebn9581g3MXXt1sWksAniCP
3FWuLKdtgIoXTiEaMYhk7tmK
=ioQu
-----END PGP SIGNATURE-----