LARGE_INTEGER in Windows API Function

[groupw_bench]

My program calls a number of Windows API functions, with USE IFWIN declared. However, I'm unable to get SetFilePointerEx to work. According to Windows documentation, one of the parameters is type LARGE_INTEGER and another PLARGE_INTEGER. I've tried declaring the LARGE_INTEGER parameter (liDistanceToMove) in each of the following ways (one at a time):

INTEGER (LARGE_INTEGER) :: liDistanceToMove

----------

TYPE (LARGE_INTEGER) :: liDistanceToMove

----------

INTEGER (KIND = 8) :: liDistanceToMove

-----------

TYPE LARGE_INTEGER

   SEQUENCE

   INTEGER (DWORD) :: LowPart

   INTEGER (DWORD) :: HighPart

END TYPE

TYPE (LARGE_INTEGER) :: liDistanceToMove

------------

None of these work. The most common error is #6633, that the type of the actual argment differs from the dummy argument.

How do I declare this parameter (and the PLARGE_INTEGER type)?

[Anthony_Richards]

According to MSDN "Windows NT defines a LARGE_INTEGER data type that is a 64-bit integer created from an array of two longwords. A LARGE_INTEGER type is not the same as a quadword. The quadword is a true, nonportable, 64-bit integer data type; the Windows NT LARGE_INTEGER is a data type that is 8 bytes in size and is usable as a 64-bit integer only in conjunction with a set of run-time library functions. You should not redefine the LARGE_INTEGER type." Note the last sentence. Also see here for LARGE_INTEGER structure. http://msdn.microsoft.com/en-us/library/windows/desktop/aa383713%28v=vs.85%29.aspx

[TimP]

One would think LARGE_INTEGER should be compatible with integer(C_INT64_T) and PLARGE_INTEGER with integer(C_INTPTR_T), should IFWINTY not offer suitable definitions. Are you hinting that you have to turn off gen-interfaces? That would indicate there are definitions in a .mod which conflict with yours. The doc suggests you look in to the source of IFWIN. I'm wondering if the sources are still supplied, as they were at the time the doc was written. It might be useful to have a complete reproducer.

[jimdempseyatthecove]

Try adding USE IFWINTY By historical convention, MS C/C++ chose to make LARGE_INTEGER a struct and not a __int64 (int64_t, ...). This struct does contain a QuadPart member unioned with the {DWORD LowPart, DWORD HighPart}. In IVF this convention is followed by making LARGE_INTEGER (e.g. T_LARGE_INTEGERX) a type that on x64 platform has "integer(8) value" and on x32 platform has a sequenced "integer(4) LowPart; integer(4) HighPart". This declaration is in IFWINTY As TimP mentioned: Do not redefine a type defined by a provided module (i.e. USE the module containing the definition) Jim Dempsey

[Paul_Curtis]

Here's how I control the file pointer, with the regular version of the API function and absolute position within the file: [fortran] RECURSIVE SUBROUTINE Set_File_Pointer (ihandl, offset, truncate) IMPLICIT NONE INTEGER(HANDLE), INTENT(IN) :: ihandl INTEGER, INTENT(IN) :: offset LOGICAL, INTENT(IN), OPTIONAL :: truncate INTEGER :: rslt rslt = SetFilePointer (ihandl, MAX0(offset,0), NULL, FILE_BEGIN) IF (PRESENT(truncate)) rslt = SetEndOfFile (ihandl) END SUBROUTINE Set_File_Pointer [/fortran]

[JVanB]

The thing you are forgetting is that ifort prepends "T_" to Windows user-defined types. Thus you need T_LARGE_INTEGER to make this work.

[JVanB]

BTW you can look this up in ifwinty.f90 and use TRANSFER to convert back and forth between INTEGER(8) and T_LARGE_INTEGER.

[groupw_bench]

Thanks very much, Repeat Offender. Of all the responses, yours were the ones which actually answered my question. The compiler is happy when I declare both variables as TYPE (T_LARGE_INTEGER). I found the definition of this type in IFWINTY.f90. The TRANSFER tip is very helpful, too. Thanks again.