Това код от Атмел. Би трябвало и да работи. Но нещо не схващам идеята. Някой ще ме насочи ли в правилната посока на мислене?

Някаква безсмислена форма на скаларна инициализация.


Върши точно същата работа. Другото трябва да ти е ясно.

ми не, това е обект от тип указател и той се инициализира с нула.

Докато в декларацията на атмел има 2 обекта:
- масив с един елемент, който се инициализира с нула
- указател, който си инициализира с адреса на масива.


Проблемът в кода е че пишат във втори елемент на масива... Това е бъг Никола, въпреки че много компилатори биха заделили 4 байта, заради подравняване и т.н. Демек може и да не прави бели в кокретния случай, но си е мазане по паметта. Освен това масивът е за инициализация и е друга секция/памет и не е редно да се пише по него дори и по първия и единствен елемент.

"много компилатори биха заделили 4 байта"

В случая с този код направен да работи за AVR32 ще стане точно така. Това бил трика. Но е безмислено да се пише толкова криво.

Мерси за помоща

Миро, сигурен ли си? Понеже го проверих преди да пиша.

да, сигурен съм!

Фигурните скобки в инициализации значат масив или POD структура. В случая масив.

Съответно едно е да инициализираш указател с нула, друго е с адреса на масив, съдържащ елемент с нулева стойност. Съвсем различни бири са.

Тук намерих друг такъв код. Тук вече е по голмо оливане. Така като си разсъждавам pack се инициализира с масив от един елемент който физически се намира в стека. После наблъскват в стека wr_buffer след първите два байта. И би трябвало да става голямо мазало. Но този код е част от ASF на Атмел за AVR32 и би трябвало доста хора да са го ползвали. И това вече ме озадачава. Нещо може да не е както си мисля.

Не може ли да се види на дизасемблито какво се случва ?

Най-вероятно оригиналният код е бил:


но динамичните масиви са GCC разширение и сигурно са правили порт за друг компилатор. Но са я докарали само до там да се компилира... въпреки че е пълна боза, няма как да работи. Моят съвет е да видиш за по прясна версия. Аз така гледах някакъв код на Чибито дето Цецо каза че работи,
но аз явно съм гледал незавършена версия...

такива програмисти трябва да се бесят по стълбовете...

Хубаво е че си сигурен, защото нали ти казах че го проверих преди да пиша.



Най-обикновени указатели, няма заделяне.
Бира пия вече не толкова много.

мда, указателите са едни и същи, независимо към какво сочат, а точно там е разликата...
Радвам се, че не пиеш бира щото не съм ти предлагал

добре де, аз ще ви почерпя по една бира...

този код, дори и да се изпълнява правилно, и дори да е (вероятно) синтактично правилен, не ми изглежда семантично ясен.
не виждам причина да се пише триково, когато може да се напише по-разбираемо, дори и резултата да е 20 байта повече код.
това, с недомлъвките в кода, е младеШко увлечение.

Дедо, виж по-горе как си мисля, че е изглеждал кода преди да го омажат... Съвсем читав изглежда, като изключим че е GCC специфичен.

Целият проблем е, че на високо ниво АПИ-тата трябва да боравят с чисти данни. Клиента казва запиши ей тоз буфер с такава дължина и не се интересува в каква памет ще се пише, с какъв интерфейс и т.н. Така и трябва да бъде.

На ниско ниво обаче различните памети искат различни команди преди данните, в случая И2Ц-то иска адрес. От друга страна пък функциите за писане по хардуера искат всичко да е в един буфер. И не става първо да пратиш служебните данни после истинските с друга транзакция. Ех, не става с тоя тип библиотеки.... аз затова не ползвам такива неща

Та проблемът е че за да се пратят накуп им трябва нов буфер да се сглобят служебните данни с пейлоада. На чисто Ц нямаш голям избор... динамична памет не е желателно да ползваш. Единственият вариант е да заделиш някъде достатъчно памет с максималния размер... Грозно е и затова предлагам някой се е изкушил да ползва ГЦЦ екстри. А после някой е решил да ползва друг компилатор. Вероятно е ползвал друга част от библиотеката и това го е "замазал" само колкото да се компилира останалото... Случват се такива неща, че и по-лоши

pack[0] съдържа старшия байт на start_address, а pack[1] - младшия, кво толкова неясно има. Въпроса е, че &-операцията най-вероятно е излишна, освен това масива е инициализиран само с един елемент.