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



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

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


почему так? ведь должно плучиться 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 раза он проделывает  ОПЕРАЦИЮ СЛОЖЕНИЯ верно а в  раз - нет!