Здравствуйте, Alekzander, Вы писали:

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

A>А если серьёзно. Это хорошая шутка, но плохой аргумент. Если у тебя чип горит от 101, надо использовать специальный mocking-чип, у которого от 101 горит только лампочка на крышке и активно использовать автотесты, а не возлагать всю полноту ответственности на компилятор и чекеры.

Шутка не моя, да, и ей лет 15 минимум. Может, ещё советских времён. Но она тут в тему.

В вашей реплике есть принципиальная ошибка и подтасовка: с чего вы взяли, что я собрался этими методами возложить "_всю_ полноту ответственности" на компилятор и чекеры? Разумеется, тесты будут. Скорее, конечно, не с "mocking чипом", а с mocking HAL: перехват будет минимум в функции, которая собственно делает запись в регистры или что там вместо них. А если дадут возможность (буду активно пинать) — и в реальном HAL, если такая проверка не будет в разы дороже самой записи.

Основная проблема же в том, что если контроля на выходе (при записи в регистр) нет, а дальше полагаться только на тесты — то какая-то часть случаев таки будет выходить насквозь. Никакие тесты тут на абсолютны и не всенадёжны, даже признак 100% покрытия недостаточен, проблема может быть в комбинации условий и ситуаций. А дальше начинает работать тот фактор, что отлавливать ошибки как можно ближе к месту их возникновения, а в идеале в самом этом месте — в разы и десятки раз дешевле, чем даже на пару уровней вызовов дальше.