Необходимо осуществлять прием данных неизвестной длинны. Работаю на AVR в режиме жесткой экономии памяти. Поэтому не хотелось бы выделять буфер размером как максимально возможная длинна строки.

Сначала я сделал так



Но такой подход почему-то не работает. Какие еще есть варианты?

PS. AVR GCC

Брр.. является указателем, а не массивом... Если вы хотите использовать указатель на массив, то проинициализируйте массив также


P.S. Вообще код странный и неправильный.. Используйте буферы, так проще..

Прочитай еще раз, что делает sizeof() и подумай, почему твой код не работает.

Ко всему предыдущему самое главное - абсолютное отсутствие представления о возможностях менеджера памяти - на строку памяти жалко, а отдать здоровый кусок менеджеру и затем через заднепроходное отверстия порциями (причем далеко не байтовыми) получать и при этом ввиду отсутствия дефрагментации иметь гарантированные проблемы - это типа "нормально"......

Ну так потому я и здесь, чтобы научиться )) по-моему нормальный процесс

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

Выделять буферы в процессе работы ...
А.Робинс "Linux программирование в примерах"... Там есть один пример - чтение строки произвольной длинны... Linux-не Linux, но видно как это делают... Конечно придется работать с динамической памятью... Кстати, в самом Linux'е есть готовые системные вызовы - getline(); getdelim(); .

Тогда задавайте вопросы ОБДУМАННО.

Не имею понятия какую задачу Вы собираетесь решать. Думайте сами. Может и менеджер памяти выдающий память для полного фрейма много правильнее для Вашего случая, но то, что побайтный realloc есть полное безумие, это точно.

Кстати, об AVR - там нет и не будет ни линукса, на хотя-бы возможности создать сколь-нибудь функциональный менеджер памяти. Да и и столько ресурсов, что-бы выбросить их на монстральнейшие системные вызовы с линуксовом стиле и близко нет.

Та я это знаю. Просто вдруг кто-то через поисковик найдет тему и ему будет нужно именно это...

Функциональность устойства проста. Подключается к Ethernet через ENC28J60, TCP/IP стек- uIP. Должно отвечать на пинги. Дрыгать ножками по команде с телнета, считывать состояние других ножек, принимать новую прошивку, самопрошиваться. Настраиваться по телнету. Телнет передает посимвольно данные. Поэтому и стоит задача приема данных посимвольно.

Писать строку в дополнительный стек, растущий навстречу основному, вплоть до пересечения и краха системы

тогда зачем Вам городить непонятные конструкции? всякие данные к устройству есть команда, а команда есть конечное количество символов. Получили команду - обработали - очистили буфер. Определить максимально возможную длину команды будет несложно

Ну а теперь попробуйте объяснить, прежде всего самому себе, с кем из помянутых выше задач Вы собрались динамически делить память??!!

P.S.
В вопросе о вытаскивании себя за волосы перепрошивки самого себя по TCP/IP Вы полагаю, плаваете еще больше.
P.P.S.
Выбор железа видимо делался исключительно исключительно с целью спонсировать сразу двух производителей восьмибитовиков и для упражнений в "режиме жесткой экономии памяти"?

Выделите буфер на максимальную длину токена. А дальше - пусть Ваш девайс хоть Гамлета читает посимвольно. Это будет задача на другом уровне - кому и сколько локальных переменных требуется.

>>В вопросе о вытаскивании себя за волосы перепрошивки самого себя по TCP/IP Вы полагаю, плаваете еще больше.

Это Вопрос не этого топика. Но uIP в место для бутлоадера ну никак не влезет. Предпологается прием прошивки, запись ее во внешнюю EEPROM, потом саморебут и старт бетлоадера, прошивающего МК прошивкой из внешнего EEPROM.

Возьмите уже ARM наконец!
Ага, можно и с Ethernet PHY на борту и человеческим кол-вом памяти.
А потом посчитайте по деньгам и поймите наконец, что пошли неправильным путём изначально

Манипуляции Ваши с внешним EEPROM тоже достаточно "интересны" ))

Как раз наоборот - нормальное решение, без кавычек. Не надо городить супер-биос и продумывать системные вызовы и межпрограммные взаимодействия. Или Вы думаете, программа сама себя целиком перезапишет?

Беру свои слова обратно. Согласен. Тут же у него ещё эзернет с IP стеком... там кроме как сначала сохранить всё, потом даже проверить на валидность, а потом только шить.
Чисто из ОЗУ конечно наверное можно было-бы это дело зарулить(не на этом контроллере правда наверное), но будет обидно, если пакетики перестанут поступать как раз во время прошивки )))
Но то, что я бы не делал это всё на АВРке - это однозначно!

Вот именно по этой причине НИКАКИХ причин делать маету через заденепроходное отверстие и навешивание корове седла ввиде EEPROM а не нормальный бутовый загрузчик с минималистичной поддержкой TCP нет. Ну и то, что идет работа по http://www.telesys.ru/wwwboards/mcontrol/2...es/592756.shtml это, к сожалению, факт.

Иногда, в таких случаях удобно использовать циклический буфер.

Есть. Если очень хочется, чтобы в случае "недопереписал" можно было бы гарантированно откатиться назад. Правда, надо догадаться делать свопинг страниц но это уже совсем другая песня.

Есть - не выделять буфера вообще, а обрабатывать поступающие символы 'на лету'. Единственный недостаток - нельзя будет редактировать входную строку.