Re: Re[2]: bufer owerflow in my progs
> VW> писаться раньше чем сами программы.
> согласен, делал когда, не знал как сделать ту или иную крупную
> процедуру
Делай даже для мелких. Очень способствует. Ибо errare human est.
>
> VW> А еще -Wall и lclint иногда
> первым пользуюсь постоянно а вот о втором слышу впервые
Ну скажи apt-get install lclint и почитай документацию, погоняй через него
свои программы. Может понравится.
> VW> помогают. Всяческие Electric Fence и libsave помогают только если у
> VW> программиста случился ступор и он не видит очевидой глюки в своем коде.
> у меня похоже часто такое случается - я эти вопросы решаю просто -
> этакой зачисткой с начала и до конца всей процедуры - это всегда
> помогает (переделка или упрощение алгоритмов) заоднем и ощибки
> исчезают
Вот это и есть правильный метод. Только его надо применять сначала, а не
когда уже не работает.
> VW> Гораздо полезнее четкое понимание структуры программы и расстановка
> VW> assert-ов в соответствии с этим пониманием.
> ^^^^^^ что это ?
По-моему, этому программиста на C должны учить сразу после того как
вводится понятие функции (потому что в безструктурной программе от них все
равно никакого толку). Это такой макрос, который проверяет условие
(assertion) которое не может быть нарушено никогда, потому что если
оно нарушено, то все равно уже получилась чушь. Например, что результат
функции возведения в квадрат действительного числа меньше 0 (естественно,
такой assert имеет смысл, если функцию возведения в квадрат ты пишешь
сам).
Расставив в нужных местах assert-ы ты компилируешь программу с -DNDEBUG
и запускаешь. Она будет падать в корку на первом же нарушенном assert-е,
то есть не там, где ошибка чему-то помешала, а там, где она возникла.
В принципе Electric Fence делает то же самое, но только с функциями
размещения памяти.
> VW> Так что если научишься эффективно использовать vim или emacs и
> VW> Не говоря уж о том, что два упомянтуых редактора содержат в себе гораздо
> VW> больше функциональности, чем начинающий ожидает увидеть в IDE.
> в чем их преимущества например перед mcedit ?
Ну это, ты сказал... Если я начну перечислять все, чего нет в mcedit,
и без чего я не могу считать написание текста программы комфортным, то мой
sendmail пожалуй обидится на слишком большой размер письма.
тэги (автоматический поиск места определния фуннкции или переменной по
многофайловому проекту - поставил курсор на вызов функции, нажал кнопку и
получил ее определение)
букмарки, стэк буферов удаления и куча именованных буферов,
возможность повторить последнюю операцию редактирования,
вызов man по функции имя которой под курсором, одной кнопкой,
развитые операции поиска и замены.. (слабо в mcedit одной командой
поменять местами первый и второй аргументы всех функций atan2 в файле)
поиск по многим файлам, вызов make прямо из резактора и прыганье курсором
по ошибкам компиляции, фильтрация фрагментов текста через программу,
вставка в текст вывода программы
(вот например, хочу я картинку в xpm воткнуть, а она на диске у меня в gif
лежит. Я говорю :r !giftoppm|ppmtoxpm
и вот она)
Ну, и разнообразные completion само собой.
> VW> Да, а вообще, зачем
> VW> а) писать демонов? Тут для облегчения жизни inetd придумали.
> управление железом (АСУ)
Тяжелый случай. Тут драйвера в ядро писать надо (на C) а наружу из ядра
высовывать продуманный интерфейс на уровне файликов в /dev со
специфическими IOCTL, а вот с ними уже можно и из перла поработать.
> PS: Вообще конкретно меня беспокоит что при старте демона из инит на stderr сыпются
> сообщения типа failed free memory for init,watchdog,inetd,apache итд
> итп включая мою прогу, в тоже время при запуске демона руками - все
> нормально.
Это что-то у тебя на уровне системы не так. У меня подобные ругательствва
бывали когда модперловый скрипт уходил в бесконечную рекурсию и отжирал
гигабайт виртуальной памяти.
Плохо жить в системе, где ulimit-ы на память не работают.
--
Victor Wagner vitus@ice.ru
Programmer Office:7-(095)-785-09-72
Communiware.Net Home: 7-(095)-135-46-61
http://www.communiware.net http://www.ice.ru/~vitus
Reply to: