в общем имеется такой код:



отладочная информация перед входом в цикл

после первого прохода:


почему так? ведь должно плучиться 0x00346858?!
может так нельзя?

attr = attr +  attr->length; замени  на 
attr = attr +  attr->length/siizeof(attr)

результат 0x003469c0, а что это даст? ведь размер по-любому 4 байта.

ps вообще-то NR_ATTR_HEADER - структура.

Это сообщение отредактировал(а) Logree - 17.9.2010, 20:22

у вас есть указатель на какой-нибудь тип.
например:


делая инкремент ptr, вы получаете адрес следующего элемента


в адресной арифметике это выглядит примерно так:
указатель на тип + число = адрес памяти + число * размер типа

доходчиво?

нет не понял, покажите пожалуйста на моём примере как нужно 


вот так работает:

правда после 3 итерации опять адреса начинают ехать...

кто нибудь может внятно и просто(с примером) объяснить - почему?

Это сообщение отредактировал(а) Logree - 17.9.2010, 21:31

это то же самое, что и


смещение у вас должно быть единицами NR_ATTR_HEADER, а не адресом.

а так?

Это сообщение отредактировал(а) ilyagoo - 17.9.2010, 22:04

Все, до меня дошло  я не знал что attr->length автоматически умножается на sizeof(NR_ATTR_HEADER)
Но почему со временем адреса едут? из-за погрешности деления?

какие погрешности? деление у вас там целочисленное. 13 / 5 = 2 ))
вообще по коду совершенно не понятно, что он мог бы делать. а раз так - то он НЕВЕРЕН. перепишите, не поленИтесь.

и лучше не использовать адресную арифметику, уж больно она платформо-зависима. пишите attr[ index ].

это смотря в какую сторону округлять)


я последовательно "перемещаю" структуру по области памяти.



Вот к примеру на протяжение 3 шагов смотрю в отладчик:

0:

1:

2:

3:


ведь первые 2 раза складывает верно, а других операций там нет, с чем может бытть связано?

Это сообщение отредактировал(а) Logree - 17.9.2010, 23:56

attr[index] - это тоже самое, что *(attr + index). А адресная арифметика четко прописана в стандарте и она гарантируется точное позиционирование на нужный элемент.

мало ли что и где написано, все зависит от реализации.
мне, например неочевидно что содержится в attr->length и что такое 0xFFFF.

ilyagoo, точно платформо-независимая, язык гарантирует это.
Другое дело, что *(attr + index)  может выглядеть сложнее attr[ index ].
Но по количеству проблем они абсолютно идентичны, ни в первом ни во втором случае никаких проверок индекса не производиться.
Поэтому если нет специальных показаний (по быстродействию), использовать в чистом виде такие варианты доступа к данным не желательно.

данный кусок кода перебирает атрибуты файловой записи таблицы MFT, для NTFS, в buffer содержиться сама файловая запись, атрибуты располагаются друг за другом, так что для того чтобы перейти к следующему атрибуту нужно к текущему смещению атрибута прибавить его длинну и чтобы не копировать каждый раз данные я просто перемещаю структуру как маску куда мне нужно, список атрибутов заканчивается терминатором 0xFFFFFFFF, но пока что сойдёт и 0xFFFF.

однако, все это ни как не относится к проблеме, но если поможет её решить - буду рад 



Это сообщение отредактировал(а) Logree - 18.9.2010, 02:01

1. выравнивание? структуры точно лежат подряд  без пустых байтов между ними?
2. Там только  структуры NR_ATTR_HEADER или могут лежать другие, у которых первым элементом является NR_ATTR_HEADER? судя по отладке именно этот случай.



Это сообщение отредактировал(а) vnf - 18.9.2010, 10:47

1. Друг за другом,вплотную, поле length по сути является смещением следующего атрибута.
2. нет там только структуры NR_ATTR_HEADER, они закончаться когда type == FFFF

если не правильное значение 0x003468d0 заменить на то что и должно было получиться - 0x003468e0 то всё становится на свои места.
я не понимаю, 2 раза он проделывает  ОПЕРАЦИЮ СЛОЖЕНИЯ верно а в  раз - нет!

Сделал так:


работает, но почему как в предыдущем варианте не прошло?

Logree, а почитать инструкцию к языку программирования не пробовал?

Вот смотри, у тебя на столе лежат в ряд 10 апельсинов. При этом ты знаешь, что диаметр апельсина 100 мм. Чтобы дотянуться до следующего апельсина тебе нужно дать команду руке на позиционирование руку на 100 мм или на 1 апельсин? Конечно на 1 апельсин, так как мозг такую фигню легко и без тебя разруливает. Так и компилятор, когда у тебя есть типизированный указатель, то прибавление/вычитание целого числа приведет к смещению этого указателя на указанное число элементов (т.е. в данном случае предполагается, что указатель ссылается на массив однотипных объектов).
В своем первом коде, ты давал команду сдвинуться не на 1, а на 100. Вот только компилятору ты не сказал, что тебе нужно не 100 "апельсинов", а 100 "миллиметров". А для него по умолчанию это значит именно "апельсины". Чтобы твой код работал правильно, нужно делать так:Но у меня работало и так:

Это сообщение отредактировал(а) bsa - 19.9.2010, 19:16

я не так часто пишу на Си, так что каждый раз приходиться все вспоминать заново 

спасибо всем.

А смещение length - это в байтах или в структрурах NR_ATTR_HEADER? Таки скорее всего первое, поэтому attr = (NR_ATTR_HEADER *) ((LPBYTE)attr +  attr->length); ?

(BYTE *) !=== (LPBYTE)?

http://forum.vingrad.ru/act-ST/f-92/t-212832.html

Откройте ассемблерный листинг в отладке и сравните код с LPBYTE и с BYTE*.
mov eax,dword ptr [ebp-18h] ; attr
mov ecx,dword ptr [ebp-18h] ; attr
add ecx,dword ptr [eax+8] ; attr->length
mov  dword ptr [ebp-18h],ecx ; сумма

Равен он, равен