AF
Size: a a a
2020 December 15
m
В си++ и это уб
Так это детали реализации winapi, пользователя winapi это не затрагивает.
m
`
DRIVE_LAYOUT_INFORMATION_EX *` на хипе?Если речь о
new DRIVE_LAYOUT_INFORMATION_EX, то это не решение, так как api будет писать за границами объекта.2020 December 16
m
По идее правильное решение использовать placement new перед вызовом winapi, чтобы корректно прочитать
DRIVE_LAYOUT_INFORMATION_EX. А для того чтобы прочитать все остальное формально надо изголяться с чем-нибудь вроде bit_cast, который работает через копирование. Других честных решений я не придумал.D
По идее правильное решение использовать placement new перед вызовом winapi, чтобы корректно прочитать
DRIVE_LAYOUT_INFORMATION_EX. А для того чтобы прочитать все остальное формально надо изголяться с чем-нибудь вроде bit_cast, который работает через копирование. Других честных решений я не придумал.Чисто теоретически, можно использовать placement new для
Но выглядит странновато
DRIVE_LAYOUT_INFORMATION_EX и потом до конца буфера - для PARTITION_INFORMATION_EX, которые идут хвостикомНо выглядит странновато
m
Чисто теоретически, можно использовать placement new для
Но выглядит странновато
DRIVE_LAYOUT_INFORMATION_EX и потом до конца буфера - для PARTITION_INFORMATION_EX, которые идут хвостикомНо выглядит странновато
А, если можно до вызова winapi понять сколько и какого типа будут объекты в хвосте, да их можно создать вместе с заголовком. Это я не сообразил.
D
А, если можно до вызова winapi понять сколько и какого типа будут объекты в хвосте, да их можно создать вместе с заголовком. Это я не сообразил.
Тип известен, сколько - там танцы, конечно, ибо
DeviceIoControl не позволит получить число объектов сразу, придется её (по рекомендации с MSDN) вызывать в цикле, удваивая размер буфера. Вопрос целесообразности остаётся открытымm
Тип известен, сколько - там танцы, конечно, ибо
DeviceIoControl не позволит получить число объектов сразу, придется её (по рекомендации с MSDN) вызывать в цикле, удваивая размер буфера. Вопрос целесообразности остаётся открытымВ принципе если нам известен размер буфера вероятно количество объектов в хвосте можно вычислить примерно так:
(size - sizeof(_DRIVE_LAYOUT_INFORMATION_EX)) / sizeof(PARTITION_INFORMATION_EX)
А так я люблю порассуждать о UB, потому что стараюсь писать портируемый код. Но если приходится пользоваться низкоуровневыми штуками специфичными для платформы, я готов гораздо больше полагаться на особенности реализации.D
В принципе если нам известен размер буфера вероятно количество объектов в хвосте можно вычислить примерно так:
(size - sizeof(_DRIVE_LAYOUT_INFORMATION_EX)) / sizeof(PARTITION_INFORMATION_EX)
А так я люблю порассуждать о UB, потому что стараюсь писать портируемый код. Но если приходится пользоваться низкоуровневыми штуками специфичными для платформы, я готов гораздо больше полагаться на особенности реализации.Судя по особенностям реализации и ABI (и тому, как это делают в примерах на MSDN и OSR), можно вообще забить на инициализацию объектов в строке, если с выравниванием всё хорошо...
D
Вероятно их примеры написаны на чистом си, где это окей. Но я не знаю чистый си.
Да, в чистом Си это окей
Задумался: драйвер внутри юзает
Задумался: драйвер внутри юзает
RtlCopyMemory, а в текущей реализации это std::memcpy => в C++20 считается инициализацией для trivially_copyable типов, в более ранних - формально UB, но работает