像FILETIME處理結構如UInt64/Int64

在閱讀MSDN博客文章Why can't you treat a FILETIME as an __int64?後出現此問題。文章說，將FILETIME投射到__int64可以創建一個未對齊的指針。在Windows頭部聲明像FILETIME處理結構如UInt64/Int64

FILETIME，LUID和LUID_AND_ATTRIBUTES結構如下：

typedef struct FILETIME { 
     DWORD dwLowDateTime; 
     DWORD dwHighDateTime; 
    } 

    typedef struct LUID { 
     ULONG LowPart; 
     LONG HighPart; 
    } 

    typedef struct LUID_AND_ATTRIBUTES { 
     LUID Luid; 
     DWORD Attributes; 
    }

由於FILETIME和LUID結構具有類似的佈局，因此治療LUID作爲__int64還可以創建一個未對準指針。然而，Windows.pas（德爾福XE3這裏）實行this--，例如：

{$ALIGN 4} 
    LUID_AND_ATTRIBUTES = record 
    Luid  : Int64; // Here, LUID is treated as Int64 
    Attributes: DWORD; 
    end; 
    {$ALIGN ON}

另一個例子是

function LookupPrivilegeValue(lpSystemName, lpName: LPCWSTR; 
     var lpLuid: Int64): BOOL; stdcall; // LUID is treated as Int64

如何安全地像對待FILETIME或LUID直接結構爲UInt64/Int64？關鍵是什麼？

來源

2012-11-21 Astaroth

這在Delphi支持的體系結構中基本上不存在問題。如果您訪問錯誤對齊的數據，x86和x64體系結構會原諒您。另一方面，訪問Itanium上的錯誤對齊數據將導致運行時錯誤。但德爾福從未針對安騰。

重要的問題是記錄佈局。一個Int64的對齊方式爲8.但是FILETIME和LUID的對齊方式爲4.這就是爲什麼LUID_AND_ATTRIBUTES被標記爲明確的$ ALIGN 4.

如果您打算將FILETIME和LUID聲明爲Int64，那麼您需要每次在記錄中包含記錄時，都要特別小心。

來源

2012-11-21 07:07:57

@David_Heffernan，很好的解釋，謝謝。 – Astaroth

像FILETIME處理結構如UInt64/Int64

回答

相關問題