во франклине (для работы с плав арифметикой не использую, но спецэффект видел) и в кейле сталкиваюсь с тем, что sprintf мусорит в строке после полезной части. при выводе плавающего числа со спецификатором f4.1 после полезной части кидается еще байт так 9 мусора. обычно обхожу это тем, что завожу большую строку с запасом, фактически для вывода плавающего числа по спецификатору f4.1 требуется строка длиной 24 байта (с некоторым запасом), но может быть кто- то нашел лечилку?


в порядке пожарного бубна

может кому срочно поможет, как посмотрю подробнее еще отпишусь. вроде бы мусор исчезает, если вызвать последовательно сначала sprintf без поля точности: sprintf(...,"%f",....) и сразу же еще раз, но уже как нам нужно sprintf(...,"%4.3f",...).

Что-то не верится, что в кейле может быть такой глюкавый sprintf.

вот что увидел . детально как всегда нет времени.

стал использовать строку в которой формирую спецификатор. Это нужно когда скажем меняем число знаков после запятой и что-то такое.



и используем это



важно, чтобы в строке , в которой записывается спецификация, после полезной части был обязательно 0. Собственно, это определение строки. Если нуля нет , то результат будет как я описывал изначально: мусор на неопределенную глубину , причем, результат изменяется от запуска к запуску (собственно программа пошла гулять по озу пока не нарвется на 0).

А зачем все эти телодвижения с обнулением памяти и записью массива? По идее достаточно такого:

ну или такого, слегка параноидального:

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

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

По идее изменение формата sprintf не спасет буфер от поломки

Буфер ломается по какой-то другой причине. А мой комментарий насчет суровых мужиков относился к

Танцы с бубном. Очевидно, что, скорее всего, кто-то ещё гадит в стеке.
Ну и товарищ Борщ уже написал, как это правильно делается :-)

Возможно - у Вас элементарно переполняется стек.
Наблюдал на IAR+CortexM3 использование ~0.5кБ стека при вызове printf-функций.

не простая функция и приглядывать надо при использовании. пользую в 51 процессоре. озу осталось байт 300. сомневаюсь, что использует стек в регистрах, но если народ знает в каком месте print sprintf творит свое черное дело, то милости просим высказаться.


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



неплохо, но на самом деле же писал что спецификатор надо в ряде случаев менять .





вот это интересно

Под столом :-)
"О, сколько нам открытий чудных..."

ну да. за 19 лет первый раз вижу такую запись.
пад сталом я смотрел - там нету

А оно уже лет 40 в документации на язык C описано...

Так Вы что - в качестве 2-го аргумента sprintf передавали не завершающуюся нулём строку (ASCIIZ)????
Жесть....
А чего-ж Вы тогда хотели от sprintf? Правильно он Вам память и разрушил....