Hello, Dimmy Timchenko! You wrote in conference fido7.ru.embedded to Dmitry Orlov on Mon, 21 Apr
2008 10:52:20 +0400:
DT>>> Да, готовые библиотеки - увы. Разве что "врапперы" какие-нибудь DT>>> делать. :) Хотя для встроенных систем это не так критично.
DO>> Зависит. Бывает и во встраиваемых систем нужно пользоваться чужими DO>> готовыми сорцами, а не перелопачивать их.
DT> Hе приходилось. Максимум - библиотеками.
Этого уже достаточно. Для веселья достаточно несогласовано текстовый шаблон и параметры в [s]printf() передать, а реализаций С без такой возможности мне не попадалось (и надеюсь не попадется).
DT>>> Это при чтении нет большой разницы (да и то...), а при записи?
DO>> Hе вижу разницы. Последствия в любом случае одни - неправильно DO>> работающая программа.
DT> Если пишешь куда попало - последствия могут быть катастрофическими и DT> трудно определимыми.
В точности такие же, как и когда читаешь откуда попало.
DT>>> Да и проблема обычно не в "гуляющих индексах", а, например, в DT>>> выделении недостаточной памяти для буфера.
DO>> Hу а это как компилятор может проверить? Толку от рантайм проверки DO>> во встраиваемой системе - 0. Hу допустим, потеряв на каждом DO>> обращении (и на выделении каждого буфера) время и место на эти DO>> проверки программа увидела, что обращение идет мимо выделенного под DO>> объект места. Что делать?
DT> Hе все же встраиваемые системы - "невидимки".
Hе все, но огромная их часть.
DT> А если есть индикация - можно вывести диагностическое сообщение. DT> Особенно это полезно в процессе отладки.
В процессе отладки можно много чего, можно и проследить за тем, чтобы указатели куда положено указывали и индексы (суть тоже самое) тоже.
DT> А если использовать "классический" сишный подход, ошибка может DT> проявиться слишком поздно.
Что такое классический сишный подход?
DO>> У пользователя ведь не спросишь, просто ресетить, или ничего не DO>> делать, или игнорировать ошибку - все это приведет к примерно DO>> одинаковым последствиям - устройство, в которое встроен контроллер DO>> с такой программой, работает не правильно.
DT> Зато пользователь или обслуживающий персонал может сообщить DT> диагностическую информацию разработчику.
Иногда это возможно, но очень часто тебе в лучшем случае сообщат в каких условиях перестает работать, а скорее просто вернут в перемешку работающее, сгоревшее, просто ни разу не включавшееся и предоставят думать самому по какой причине.
DT> Кроме того, корректный шатдаун устройства в большинстве случаев DT> предпочтительнее неопределённого поведения. Которое может закончиться DT> и "физической" аварией.
Корректный шатдаун может произойти уже после того, как физическая авария уже
300 микросекунд как случилась...
DT> Как-то ты узко смотришь на вещи.
Отнюдь. Я просто не вижу смысла пусть не идеальный, но хорошо известный и широко применяемый инструмент курочить в надежде немного улучшить результат в немногих частных случаях. Может в них просто другой инструмент применять?
dima
formatting link