Запись TFileTime представляет 64-х битное значение в двух частях:
type
  PFileTime = ^TFileTime;
  _FILETIME = record
    dwLowDateTime: DWORD;
    dwHighDateTime: DWORD;
  end;
  TFileTime = _FILETIME;
  FILETIME = _FILETIME;
Вы можете поддаться соблазну взять запись TFileTime и обращаться с ней, как если бы она была типа Int64. В конце концов, её раскладка по памяти в точности совпадает с отпечатком памяти для 64-х битного (little-endian) Integer. Некоторые люди написали пример кода, который делает именно это.
Но почему это неверно?
Выравнивание.
Поскольку TFileTime - это запись, состоящая из двух DWORD-ов, то она требует только 4-х байтового выравнивания, поскольку его достаточно чтобы уложить каждый DWORD на допустимую границу для DWORD-ов. Для первого DWORD-а нет никакой необходимости в размещении на 8-ми байтовой границе. И, фактически, вы уже наверняка использовали запись, где это не так: запись TWin32FindData:
type
  PWin32FindDataW = ^TWin32FindDataW;
  PWin32FindData = PWin32FindDataW;
  _WIN32_FIND_DATAW = record
    dwFileAttributes: DWORD;
    ftCreationTime: TFileTime;
    ftLastAccessTime: TFileTime;
    ftLastWriteTime: TFileTime;
    nFileSizeHigh: DWORD;
    nFileSizeLow: DWORD;
    dwReserved0: DWORD;
    dwReserved1: DWORD;
    cFileName: array[0..MAX_PATH - 1] of WideChar;
    cAlternateFileName: array[0..13] of WideChar;
  end;
  _WIN32_FIND_DATA = _WIN32_FIND_DATAW;
  TWin32FindDataW = _WIN32_FIND_DATAW;
  TWin32FindData = TWin32FindDataW;
  WIN32_FIND_DATAW = _WIN32_FIND_DATAW;
  WIN32_FIND_DATA = WIN32_FIND_DATAW;
Обратите внимание, что три поля типа TFileTime появляются по смещениям 4, 12 и 20 от начала записи TWin32FindData. Они смещаются от выравнивания на 8-мь байт полем dwFileAttributes.
Поэтому приведение записи TFileTime к Int64 может создать (а в случае с TWin32FindData - обязательно создаст) указатель без выравнивания (misaligned pointer). Доступ к указателю без выравнивания возбудит исключение STATUS_DATATYPE_MISALIGNMENT на архитектурах, которые требуют наличия выравнивания в обязательном порядке.
Даже если вы работаете на всепрощающей платформе типа x86, которая автоматически выполняет исправления ошибок выравнивания, у вас всё ещё могут быть проблемы. Более подробно и с другими примерами мы ещё поговорим в следующий раз.
Упражнение: Почему эти рассуждения не применимы для записей TLargeInteger и TULargeInteger?
type
  PLargeInteger = ^TLargeInteger;
  _LARGE_INTEGER = record
    case Integer of
    0: (
      LowPart: DWORD;
      HighPart: Longint);
    1: (
      QuadPart: LONGLONG);
  end;
  TLargeInteger = Int64;
  LARGE_INTEGER = _LARGE_INTEGER;
  DWORDLONG = UInt64;
  ULONGLONG = UInt64;
  ULARGE_INTEGER = record
    case Integer of
    0: (
      LowPart: DWORD;
      HighPart: DWORD);
    1: (
      QuadPart: ULONGLONG);
  end;
  PULargeInteger = ^TULargeInteger;
  TULargeInteger = ULARGE_INTEGER;
Чего-то я не понял... Между dwLowDateTime и dwHighDateTime может появляться промежуток? А может и не появляться? о___О
ОтветитьУдалитьРечь про начало структуры. Кидается исключение EXCEPTION_DATATYPE_MISALIGNMENT. x86 просто его прячет. https://www.transl-gunsmoker.ru/2009/07/x86.html
Удалитьага...
УдалитьЕсли мы объявляем как TFileTime - то смещения выходят 0, 4, 12, 20, 28, ...
А если мы объявим как Int64 - то смещения будут уже 0, 8, 16, 24, 32, ...
Но со смещениями 8/16, как я понимаю, было бы можно читать и как два DWORD и как одно Int64 - что было бы явно удобнее?
Получается проблема только в том, что в Windows изначально исторически было объявлено как два по четыре? И просто она ожидает такие?
а... Получается ещё и читать/писать как одно единое Int64 уже тоже нельзя по-хорошему? ээх))
УдалитьВот про TLargeInteger и TULargeInteger не понял, второе это вариантная запись, а первое вообще вон просто псевдоним для Int64...
Какие именно "рассуждения"? С ними ж тоже неправильные смещения выходят. Кстати, а как-то можно в отладчике посмотреть какие смещения у полей записей?
Да, всё правильно поняли.
УдалитьСмещения можно посмотреть, например, так:
var R: TSomeRecord;
Offset := NativeUInt(@R.SomeField) - NativeUInt(@R);
Выравнивание начала записи можно посмотреть просто по адресу её начала. Оно должно быть кратно (делиться нацело) 4 (для DWORD) и 8 (для Int64).
Насчёт последних записей: поскольку они вариантные - они говорят, что одна и та же память может рассматриваться и как два DWORD-а, и как одно значение Int64. Следовательно, для всей структуры в целом будет использоваться самое строгое выравнивание из требуемых - т.е. выравнивание для Int64. Таким образом, эта запись всегда будет выравниваться на 8 байт, и, следовательно, её безопасно кастовать к Int64.
Большое спасибо!
УдалитьКак вручную-то посчитать смещения я понимаю... Просто что делать если полей много?
Взять ту же TWin32FindData - 10 полей, некоторые из полей сами состоят из полей.
Есть ли какой-то механизм, чтоб сразу давал полный отчёт?
В отладчике, штатно - вроде никак. Возможно, удастся написать визуализатор для отладчика.
УдалитьЕсли для записи есть RTTI - можно попробовать через него. Мне лень думать.
Всё равно спасибо!
УдалитьА то я в отладчике не нашёл, думаю вдруг действительно просто не нашёл, а есть.
RTTI попробую сам потыкать палочкой, спасибо. С: