Локальный буфер выделяется на стеке, еще здоровый кусок от него может откусить sprintf.
Ограничение определяется размером стека и только.

Похоже. У меня в sprintf строка в 290байт. Как это ограничение обойти?

Сообщение отредактировал Димон Безпарольный - Aug 22 2017, 21:44

1. Увеличить размер стека

И еще постараться:
2. Не держать локальные буферы по полкилобайта
3. Не формировать sprintf'ом строки по 290 байт

Это весьма расточительно, если всей памяти десятки килобайт.

1. Буду благодарен если намекнете как.

2,3 Что делать если надо сформировать строку:



Бред конечно - но не я диктую моду...

Даже намекнуть не могу, так как это зависит от используемого инструментария,
структуры проекта и т.п., и по-хорошему должно быть известно только вам.

Посмотрите документацию на компилятор, там наверняка описан некий традиционный
способ установки размера стека. Сравните с тем, что имеете в своем проекте и
внесите коррективы.

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


Разделить её на кучу мелких по числу param.

Надо начать с вопроса: "А зачем её формировать в этом буфере"? И можно ли без этого обойтись?
Я вот тоже сейчас например в текущем проекте распарсиваю и формирую "модные" JSON-сообщения в несколько кБ (а возможно вырастут до сотен кБ), обходясь буферами в десятки-сотни байт. Без каких-либо проблем.

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

Заказчик очень хочет чтобы эта кишка не разбивалась.

Заполнять буфер тоже можно частями. Посмотрите, что возвращает функция sprintf.

Согласен. Но буфер должен быть единым. Т.е. больше 256 байт. И локальным его не удается пока сделать. Сделал в лоб - объявил глобальным. Работает. Но не нравится нагрузка на память.

Есть такая вещь, как динамическое выделение памяти. Но применять его пока не советую, нужно сначала со стеками разобраться.

Вот точно так же можно и отправляемую строку по частям напечатать. Я именно так и делаю. Писал выше. У меня строки размером до десятка кБ (а будут много больше). И печатают они в Ethernet-кадры, размер которых 576 байт


Нет. Если включить голову, то печатать можно окнами через тот же ..printf.
И кучу тоже не использую - печать сразу в Ethernet-кадры.

Я правильно понял, что ТС не выяснил, сколько у него стека, и сколько его расходуется? И не планирует этим заниматься? Если так, помочь тут нечем, сушите вёсла.

Ковырялся. Пока не получилось. Методику ищу, изучаю. Не факт что осилю.

й
Она сериализатором по частям не обрабатывается. Т.е. можно и свой сериализатор написать. Но боюсь времени не хватит.

Есть полезная штука по крайней мере у Кейла:
При компиляции опасные функции обрамляются ватермарком и при его повреждении - вызывается специальная функция.

http://www.keil.com/support/man/docs/armcc...59124940593.htm

Если компилятор - IAR, то там есть встроенная функция контроля переполнения стека.