Why can't you regard a FILETIME structure as _ int64?

Http://blog.csdn.net/itlionwoo/article/details/659459

The FILETIME structure is a 64-bit value, which is divided into two parts:

typedef struct _FILETIME {

  DWORD dwLowDateTime;

  DWORD dwHighDateTime;

} FILETIME, *PFILETIME;

You may be confused.FILETIMEStructure as_ Int64 for direct access. In fact, its memory distribution is the same as a 64-bit integer. The following is an example: 

Pi = (_ int64 *) & ft; // Error

 

(* Pi) + = (_ int64) num * datepart; // Error

Why is this an error?

Bytes alignment is ignored.

FILETIMEIt is a structure composed of two Dwords, which only requires four bytes to be aligned, so this is enough to align each DWORD to a valid DWORD boundary. You do not need to align the first DWORD to eight bytes. In fact, you may have used a structure, but this structure is not so aligned: WIN32_FIND_DATA structure.

typedef struct _WIN32_FIND_DATA {

    DWORD dwFileAttributes;

    FILETIME ftCreationTime;

    FILETIME ftLastAccessTime;

    FILETIME ftLastWriteTime;

    DWORD nFileSizeHigh;

    DWORD nFileSizeLow;

    DWORD dwReserved0;

    DWORD dwReserved1;

    TCHAR  cFileName[ MAX_PATH ];

    TCHAR  cAlternateFileName[ 14 ];

} WIN32_FIND_DATA, *PWIN32_FIND_DATA, *LPWIN32_FIND_DATA;

Through analysis, the three FILETIME structures appear in the 20th and bytes starting with the WIN32_FIND_DATA structure. They have beendwFileAttributesThe Member has lost the 8-byte alignment feature. Observe that the threeFILETIME
Structures appear at offsets 4, 12, and 20 from the beginning of
Structure. They have been thrown off 8-byte alignment bydwFileAttributesMember.

Forcibly convert FILETIME_ Int64 (in WIN32_FIND_DATA) To get a non-byte alignment pointer. Accessing a non-byte alignment pointer on the frame that requires byte alignment will causeSTATUS_DATATYPE_MISALIGNMENTException.

Even if your platform can automatically correct this alignment problem, you will still cause problems. Thinking: WhyLARGE_INTEGERAndIs there a problem with the ULARGE_INTEGER structure?

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

Then how is the conversion scheme?

Http://stackoverflow.com/questions/1566645/filetime-to-int64

I gave an example of an error. Do you think it is caused by direct shift? Because it will not overflow after being converted to int64? Is that true? If you have time, you can try it. I didn't try it.

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

3 down vote

I don't think you're suppose to: "Do not cast a pointer toFILETIMEStructure to eitherULARGE_INTEGER*Or__int64*Value because it can cause alignment faults on 64-bit Windows ." Source. If you really wanted it wocould be something like: __int64 to_int64(FILETIME ft) {     returnstatic_cast<__int64>(ft.dwHighDateTime)<<32| ft.dwLowDateTime; } FILETIME ft =// ... __int64 t = to_int64(ft); But something like: FILETIME ft =// ... __int64 t =*reinterpet_cast<__int64*>(&ft); Is bad.

Some people say this.

Try

(__int64(filetime.dwHighDateTime)<<32)| __int64(filetime.dwLowDateTime)

------------------------------------------------ My nausea is like this: unsigned _ int64 t; t = sr. FindData. ftLastWriteTime. dwHighDateTime;
T = t <32;
T = t + sr. FindData. ftLastWriteTime. dwLowDateTime;