Заметил неприятную фичу. Если в printf или его производных не соответствуют строка форматирования и список параметров, то стек неприлично загаживается. Есть ли способы вылечить этот эффект опциями компилятора?
Система жутко нестабильна, надо весь пользовательский ввод обрамлять весьма интеллектуальными фильтрами, лениво... Пользователи пока не допёрли, что невинная комбинация %f во вводимых данных сносит крышу напрочь

И вообще, это фича ИАРа или особенность ARMов? Склоняюсь к первому, но проверять на других компиляторах самому, извините, == маразм.
Обрисуйте ситуацию, кому не лень, пжлст.

Дык уже многократно говорено, что printf/sprintf в IAR требует большого стека. Тем более с полнофункциональными опциями (вывод float).

Да он работает замечательно, но стоит дать в строке форматирования ссылку на несуществующий в списке параметров элемент, тут же все рушится.
Т.е. пишем строчку printf(" %d %d %d", a, b); и каюк. Похоже, компилятор достаёт из стека параметры вместо того, чтобы запомнить указатель и вернуть его при выходе. У кейла для 166 с этим проблем нет, да и вообше я не припомню компилятора, который бы так плохо себя вёл...

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

Тут ещё такое дело. Я весь ввод пользователя посылаю в поток отладки, а он проходит через vsprintf без параметров. Весело получается. Сам-то я шлю в дебаг с параметрами и, как правило, они соответствуют строке форматирования
Дурдом, проще свой форматёр написать.

А зачем при неформатированом выводе использовать vsprintf? Напишите свой xprint, который просто символы в буфер пихает. На стеке сэкономите кроме всего прочего.

Как обходить проблему я прекрасно понимаю. Дебаг - это по сути копия функции printf, она принимает любое количество параметров, дергаю её из любого места с любым количеством параметров. Теперь же приходится рзделять вызовы на безопасные и "более другие"
Грабельки, понимаешь...

Вопрос целесообразности... Отладка есть отладка.

Не, господа, чето фигня какая-то. Ну и бог с ним, что параметров мало, пойдет доставать из стека, ну напечатает вам содержимое регистров при входе в функцию, если не сильно разогнались, но ничего не попортит. Ведь ВЫЗЫВАЮЩАЯ функция подчищает за собой стек. А, давайте-ка, нам в студию исходный код, листинг, и входящие параметры, при которых падает.
Кстати, может быть падает просто разбор float при попадании какого-то лайна вместо нормального числа с плавающей точкой?

ссылка в тему
http://www.citforum.ru/security/articles/printf/
Неизвестная уязвимость функции printf
Крис Касперски

Я не скажу про IAR. Но gcc, hitech-c и другие компиляторы имеют возможности (например, через pragma) определить, что функция с переменным числом аргументов
является printf-подобной, т.е. содержит строку формата, и компилятор соответствие формата и списка аргументов будет контролировать. Это раз. Кроме того, надо быть уверенным, что включен нужный warning level -- то-есть может быть, компилятор несоответствие обнаруживает, но не сообщает об нём.




СТОП! Речь шла о контроле ошибок на этапе компиляции! Если речь идёт о валидации вводимых пользователем данных -- это отдельный разговор.

Но во-первых хотелось бы предостеречь об известной ошибке -- передаче строки, вместо первого аргумента, строки формата, функции printf или подобной. То-есть например:


Такой код не допустим! Кроме случаев, когда программист очень чётко контролирует содержимое string_variable. Разумно использовать другой код:



Другой вопрос, что вообще применение printf в таком случае не имеет смысла, потому, что в таком случае стоит использовать fputs:





Я смутно догадываюсь, что пользователи, помимо прочего, в данном случае вводят формат для printf в качестве входных данных программы. Если это сделано умышленно (а если неумышленно -- то это серьёзная ошибка), то следует обратить внимание на валидацию вводимых данных. Вручную.

Кстати, о птицах... Проект, перенесенный с 4.42 на 5.10 (арм) падал самым непристойным образом, пока не увеличил размеры юкосовых стеков (блин, еще засада с отсутствием КА плагина под юкос в 5.10, dll взятый из 4.42 не пошел). Виновник - как раз printf (похоже он стал более прожорлив до стека в 5.x).

Видимо придется извращаться с отладкой...



PS: Посетила странная мысль после написания вышеизложенного. ;-) В результате свежий KA плагин версии 2.50 "нашелся"... В самом очевидном для этого месте. После подпихивания вручную работает.