ReadFile

I'm trying to build LibTIFF with VC++ (using the supplied vcproj file). The library builds okay but hangs (on Windows 7) whenever I try to read any TIFF image file. I've discovered that the file gets opened using fopen(). But instead of passing te returned FILE* to fread(), a convoluted sequence occurs whereby the FILE* gets passed to _fileno() whose return value is then passed to the Windows function ReadFile(). ReadFile() hangs every time.

Is it safe to be doing this? I've always tended to avoid mixing and matching DOS file functions with Windows file functions.

the _fileno gets a FILE pointer and returns a handle to the file. That seems ok beside that the fileno has no error return and the return value is undefined in case the FILE pointer wasn't associated with an open file stream.

You should post the full code so that we could find out why it hangs.

Quote:

---

Originally Posted by John E

I've always tended to avoid mixing and matching DOS file functions with Windows file functions.

---

BTW, the fopen isn't a DOS function but a C runtime function.

Changing the function to use _read() instead of ReadFile() does seem to have solved the problem.

_read uses C runtime handle (file number), while ReadFile needs real OS handle.

Thanks Igor.

A bit more about the general thing:

Code:

---

FILE* -> HANDLE

#include <windows.h>
#include <stdio.h>
#include <io.h>

FILE*  f      = fopen(path, szMode);
int    handle = f->_file; // or handle = _fileno(f);
HANDLE hFile  = (HANDLE) _get_osfhandle(handle);

HANDLE -> FILE*

#include <windows.h>
#include <stdio.h>
#include <io.h>

HANDLE hFile  = CreateFile(...);
int    handle = _open_osfhandle((LONG)hFile, _mode);
FILE*  f      = fdopen(handle, szMode);

---

Quote:

---

Originally Posted by John E

Changing the function to use _read() instead of ReadFile() does seem to have solved the problem.

---

_read isn't the approbiate function that belongs to fopen but fread.

If you would post your code where it hangs we probably could show you where the issue is. In the momemnt it seems to me that you were fighting on the wrong places.

itsmeandnobodyelse - I do appreciate you trying to help but I already know where the problem lies. Please go back and read my original post, then read Igor's response, a few posts further down. My problem is occurring because the wrong type of handle is being passed to ReadFile().

I'm just about to try Igor's suggestion of converting the handle type using _get_osfhandle()

Igor, I tried your suggestion and it works fine - as long as 'handle' is within the range of low-level (POSIX style) handle numbers. Here's the code from libTIFF:-

Code:

---

static tsize_t
_tiffReadProc(thandle_t fd, tdata_t buf, tsize_t size)
{
        DWORD dwSizeRead;

        if (!ReadFile(fd, buf, size, &dwSizeRead, NULL))
                return(0);
        return ((tsize_t) dwSizeRead);
}

---

If the file was opened by libTIFF itself, 'fd' will already be a valid WinOS file handle (a long). In my case however, it can also be opened by libgdk_pixbuf in which case, it'll be a low-level, POSIX style handle (an int). For obvious reasons, the above function can't tell one from the other.

Assuming that the values would never overlap (which may or may not be a safe assumption) I could get around this problem by testing to see if 'fd' was already within the range of known WinOS values or alternatively, if it was in the range of low-level values.

At first, I hoped that a simple numerical test would suffice. But when I tried your code this morning, the value returned by _get_osfhandle() was worryingly close the the value I passed in. Can you think of any other way I could test the validity of 'fd'?

Quote:

---

Originally Posted by John E

itsmeandnobodyelse - I do appreciate you trying to help but I already know where the problem lies. Please go back and read my original post, then read Igor's response, a few posts further down. My problem is occurring because the wrong type of handle is being passed to ReadFile().

I'm just about to try Igor's suggestion of converting the handle type using _get_osfhandle()

---

Yes, I did understand that. But you are solving issues that only happened because you were mixing libraries without need (as far as I could see it). So if you would use OpenFile/ReadFile or fopen/fread or _open/_read it just had worked without any extra code and extra handling.

Okay, I understand.... My problem is that libTIFF can be used two ways.... you can open TIFF image files the recommended way - using TIFFOpen() - or you can open them with open() / fopen() etc and then manipulate the files by supplying the relevant file handle. The *nix and Apple interfaces utilise POSIX style file handles but for some bizarre reason, the Win32 interface uses WinOS handles - even though POSIX style handles would have worked perfectly well..! I've raised the issue with the libTIFF maintainers but it would be nice to find some elegant solution in the meantime.