@vt340

Допустим, я отлаживаю сишную программу на мк и, много раз нажав на разные кнопки на девайсе и на пк, попадаю-таки на сбойную функцию.
Казалось бы, делов то - исправить и заменить сбойную ф-цию, ну или хотя бы поставить временную заплатку, и продолжить отладку.
Но продолжить невозможно - только начинать всё заново - всё перекомпилировать, всё перезалить и снова нажимать на все кнопки.
И на следующей сбойной ф-ции опять всё заново, и так тупо по кругу )
Или есть варианты?

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

0

@Ymk

тоже теоретик?:) никакой принцип от этого не защитит кроме принципа "не используем указатели" (в т.ч. в библиотеках, в т.ч. не в ваших). разжевывать не буду.

0

@ftomdkir

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

По библиотекам могу сказать одно, если работа с библиотекой херачит весь проект, то надо либо пересматривать работу с этой библиотекой, либо переписывать, либо выкидывать её.

Извините, а когда вы тестируете софт под ПК(или не тестируете?) вы тоже последовательно нажимаете на кнопки чтобы попасть в нужную функцию и оттестировать её? Всё же более распространено (а главное эффективнее и имеет большее кпд) модульное тестирование, собственно поэтому сама проблема надумана. Конечно под ПК куда больше различных инструментов(каких только франкеншейнов не нарожали большие и не очень компании), найдётся монстр на любой изысканный вкус. Затраты на edit&continue просто не стоят того (если идёт речь о затратах времени одного человека), однако я не отказался бы от подобной фичи, если бы кто-то её внедрил :)

0

@vt340

Вы там ссылочку давали, я прочитал этот снобский рассказик )) Однако там есть один интересный коммент к нему ;)

0

@trimktor

Странно, и как это ты до сих пор выжил? (шутка)

Т.е. ты хочешь сказать, что обладание группой допуска никак не сказывается на отношении обладателя (как в период аттестованности, так и в дальнейшем) на отношении к электричеству в целом. Ну Ок, я тебя понял. То-то ты так на этот вопрос возбудился, как я посмотрю :)

0

@ftomdkir

Да, мне он тоже понравился. Бывает и такое. Очень часто грешат этим америкосские форумы, различные stackoverflow и прочие, когда задаёшь конкретный вопрос, а тебе 100500 ответов "а нафига тебе, возможно ты имел в виду <какая-нибудь ересь>?" Причём все слизанные друг у друга под копирку.

0

@vt340

и можно ещё слово Электричество с большой буквы )) Убедительно прошу всех гуру пром автоматики не испытывать моё терпение второй раз )

0

@dosykus_2

vt340, бывает и довольно часто. И если бы пациент выкладывал не свое видение процесса а суть реализации - подобного бы не происходило...

Достаточно ответить себе - какое отношение группа допуска имела к теме срача , кроме попытки возвысить свое ЧСВ...

0

@vt340

dosykus_2, я забыл ответить про библиотеки в rom - да, я знаю эту техасскую нигию ) но в стелларисваре (или теперь наверно тиваваре?) не было методов как их делать, были только - как их использовать, а использовать надо было, кажется, тупо по абсолютным адресам точек входа, въявную забитых в хидерах стандартной библиотеки

0

@Ymk

теоретик. когда пишешь один сам небольшую программку - да, ок, сильно не накосячишь. когда программа большая, когда ее писали много людей - всё совсем не так просто. да, это говнокод, но он будет. такова практика в отличие от теории.
ну говорю же - теоретик:) на практике в больших проектах сплошь и рядом встречаются всякие use after free, double free и прочие дела. дай любой стандартной си-функции неверный указатель, неверную длину - и она что-нибудь перепишет в чужой памяти. на что это повлияет - это как повезет. я видел (и фиксил) много таких косяков, в половине случаев оно вполне себе случайно работало. до поры до времени.

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

0

@dosykus_2

Угу, счас они раскрыли все свои плюшки. Зато какое раздолье хомячкам - и никто не обвинит что либы тухлыепухлые. :))))

0

@ftomdkir

Вы решили уподобиться demiurgу аля "сама придумала - сама обиделась"? Он также себе в свою задницу вбил что я ПКшный программист с потоковым "мышлением".

На практике говнокод будет всегда, но это не означает что "весь мир гавно". Да и разный он бывает.

И из той же практики я прекрасно знаю что "много людей" к телу допускать нельзя, а также нужно следить за качеством софта. Не думаешь ли ты что все эти правила "мержить в основную ветку репозитория должен только ОДИН человек" писали просто так? Уж сколько книжек написано про "хирургические бригады", "рефакторинг" и прочее, нет же, мы считаем себя самыми умными и "а хрен с ним давайте сделаем побыстрее". Вам этот код потом сопровождать вообще-то.

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

Каждый сам кузнец собственного щасья, как говорится.

0

@vt340

Эх... появился бы сейчас 8086 в виде мк, хоть с каким то кол-вом встроенного рам и флэша, и за разумные деньги, махнул бы с кортексов не глядя, только из-за ПО - мой любимый TopSpeed идеально подошёл бы для мк, без всех этих gcc-извратов )

0

@ftomdkir

Эх... появился бы сейчас 8086 в виде мк, хоть с каким то кол-вом встроенного рам и флэша, и за разумные деньги, махнул бы с кортексов не глядя, только из-за ПО ))
У армов разве нет всех фишек тех же самых? VisualGDB в своё время для меня сделало прекрасную нигию в Visual Studyo, когда я какой то арм дебажил.

0

@vt340

Да я шучу ) и 8086 нужен с jtag-ом, конечно ) Если серъёзно - досовские компиляторы были специально заточены для нижнего уровня, вот например объявление массива векторов прерываний в topspeed modula-2 сразу с явной привязкой к физ адресу -
IntTab[0:0] : ARRAY [0..255] OF FarADDRESS;
И последующее заталкивание в вектор процедуры обработчика прерывания -
IntTab[11] := FarADR(IntProc);
И это всё - никаких доп defyme, volatile, ассемблерных stortup-ов, ld-скриптов и т.п. )

0

@Ymk

при чем здесь мир говно или не говно? речь о чем шла? о том, что используя указатели люди всё равно совершают ошибки, даже пытаясь придерживаться правил. именно указатели - зло с т.з. надежности кода. и не важно где они, у тебя в коде или в библиотеке, сама их суть такова. и именно они позволяют сделать нигию "светодиод загорелся - реактор взорвался". именно они тебе не дадут проверить код помодульно и быть уверенным, что всё ок.

у нас конечно код с 30-летней историей, за который отвечаю сейчас я. и я не могу недопустить "такой херни среди многих десятков тех, кто писал тот код". да и даже сейчас, подчиненные пишут код, я его проверяю, иногда и после меня делают ревью старшие товарищи, но нет-нет и всё равно пролазит баг, о котором сообщает всего один пользователь, у которого звезды легли "как надо". да, это сложный и запутанный говнокод, который надо бы переписать, но никто этого в здравом уме делать не будет. вот она - практика.

кроме того, не верите мне - почитайте статьи про проверку разных проектов pvs-studyo, в т.ч. тех проектов, которые тоже проверяются анализаторами кода. все равно там ошибки есть. или взгляните на любой большой массовый продукт, firefox, chrome, whatever... в каждом есть ошибки несмотря на то, что пишут это всё далеко не дураки, но везде есть порча памяти и прочее. вот практика.
если не понятно, речь не о говнокоде в либе, а в использовании либой указателей. например, достаточно сделать free() второй раз и хз что хз где, но попорчено. это не либа плохая, это ее плохо вызывают. в изолированных модульных тестах ошибку можно и незаметить, все может сработать и ничего не попортиться. а в боевых условиях память между первым и вторым free() изменится и последствия будут уже совсем другие (на таких ошибках играют эксплоиты, например, заставляя вторым free переписать нужную память). но всё это - следствие указателей.

0

@ftomdkir

Ну разговор изначально всё же не про указатели был. Баги они будут всегда, никуда от них не деться.

На ПК то есть куча средств чтобы отследить утечки памяти, корректность её освобождения. Тот же PVS.

Я вот только одного не пойму, мы сейчас про ПК говорим или про МК? Вы используете динамическую память в контроллере? Если вы используете динамическую память в контроллере, то уж извините, здесь как говорится "сам дурак". Не мне судить нужно ли это в вашей ситуации или нет, но тогда уж конечно, получите и распишитесь. Недаром оно идёт чуть ли не первым пунктом в "списке зла". Так то конечно если рухнет какая нибудь "подсистема памяти", то это крах всего проекта, такое тестами не ловится, поэтому и существуют испытания конечного устройства.

0

@Ymk

да вот было, использовал и rtos, и malloc в мк. а зачем в компиляторах для мк реализуют malloc? значит надо. но это всего лишь один из примеров. гораздо проще пример с sprymtf, str* и прочими, там тоже указатели, тоже бывает портят что-то не то. так что пофиг, мк или пк, всё одинаково. везде можно взорвать реактор.

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

0

@ftomdkir

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

0

@Ymk

хех, ну т.е. реактор-таки взорвал:) зачем тогда было сказано это?

0

@ftomdkir

Несколько неверно выразился, бывает намного реже.

0