- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
template <typename function_type, typename vector_type>
function_type read_memory(HANDLE hProcess, function_type base_address, std::vector< vector_type >&& offsets) {
function_type tmp = base_address;
for (function_type i : **reinterpret_cast< vector_type** >( &offsets )) {
ReadProcessMemory(hProcess, reinterpret_cast< PBYTE* >( tmp + i ), &tmp, sizeof(function_type), nullptr);
}
return tmp;
}
int main() {
std::vector< DWORD > offset = {
0x10,
0x14,
0x158
};
auto buffer = read_memory< DWORD, DWORD >(hProcess, base_address, std::move(offset));
}
Follow us!
⅞ как минимум, и то при условии, что hProcess в спячку отправили предварительно
Чем их не устроили int8 int16 int32 и проч?
когда полез гуглить, первым же делом вывалилось конечно "не нужен вам байт у вас есть чар ты придумываешь ненужное из тебя не выйдет сишник"
хуй знает как эти пчелы собирались с какими-нибудь сетевыми октетами работать, конечно
Пиздят. Это они нубов учат юзать char, а сами тайком тайпдефят. Вон в ядре есть u8, да и в половине библиотек какие-нибудь uint8 вместо чара юзают.
З.Ы. Кстати в кресты таки завезли byte. Для настоящих битоёбов, над ним даже арифметика не работает, только побитовые операции.
На сишку нельзя полагаться. Либо код будет с проверками, которые в ближайшие годы не оттестируешь (а что, если int 128 бит), либо вообще без проверок, и тогда не скомпилируется/не заработает на машинах с int128 или charbit9.
Полагаться вообще ни на что нельзя, нужен мешок тайпдефов.
Максимум, что можно выжать из кода в плане универсальности -
Я же просил реальный пример.
§ 6.8.1/4
short int же гарантирует, что размер данных не меньше 16 бит. Т. е. 16 бит либо ближайший оптимальный для данной архитектуры размер.
В компиляторах для DSP, GPU и мейнфреймов даже char может быть не 8-битным.
Точно. Это же long 8 байт под луниксом.