ничего не увидим, потому что если это си, то синтаксис не верный, даже если написать верно Код (Text): char var1[] = {'1','2','3','4'}; то в памяти никак не будет никаких 1 2 3 4 итп цифр разве что случайно ) потому что '1' == 0x31 и вообще трудно самому глянуть что-ли ? Код (Text): char var1[] = {'1','2','3','4'}; printf("%X\n", *(DWORD*)&var1); или это стёб и я не заценил ?
я имелл ввиду если в коде "ADCD" строка, в каком случае будет CDAB а в каком DCAB переводя из кодов обратно в символы. ворды или байты меняются Имеетс ввиду что мы видим в статическом анализе в хексе
в общем, если твою строку представить как 0x31 0x32 0x33 0x34 ("1234"), и записать в память, то она расположится так: 0x34 0x33 0x32 0x31 ("4321"). Если же снова считывать из этой памяти, то ты получишь первоначальное значение. char var1 = {'1','2','3','4'}; - непонятно, где здесь неверный синтаксис, всё норм. Можно считать, как один из вариантов сохранения строки в стэке (удобно для мутации кода).
это все касательно си\++ зависит от компилера? или? или не касательно си? В чем причина? Ну простите не дочитал чутка в свое время
если рассмотреть конкретно твой пример, то да: ... mov word ptr [405000], 1234h ;[405000] = 0x34, [405001] = 0x12 если всё правильно по терминологии, то это не зависит от компилера, это архитектура процов от интел
pr0mix соотве6тственно меняется местами половины того что перемещаем эх давно они меня ждали в папке to look at
а точнее, все числа записываются в обратном порядке следования заданных байт, то есть, например, 0x12345678 будет в памяти: 0x78 0x56 0x34 0x12 (4 байта).
да, поэтому если тебе нужно как-то по особому разместить строку в памяти, то эту задачу должен решить именно ты