> А потом падают самолёты.А много самолетов упало из-за именно багов, именно в сишном коде? Если в случае ариана вполне конкретные участки кода раскопали, то в случае самолетов я встречал только
1) Горе от ума, когда airbus просто не давал сделать крутой маневр, хотя пилоту в условиях нестандартной ж-ы вызванной внешними факторами (погода) могло бы пригодиться как last resort. ЯП тут вроде в формулу не входит, только общая идея строить пилота. Боинг эту идею не любит.
2) Идиотека по поводу датчиков. Датчики ломаются и глючат. Компьютеры не всегда вменяемо реагируют на эти ситуации, иногда помогая пилотам убиться по глупой причине. Датчикопроблемы к ЯП не относятся, только к общему поведению алгоритма. Как показал пример российской ракеты, датчикопроблемы убивают и их. Хоть командоаппарат поставьте, похрен.
3) Сказочный ДЛБ-зм двуногих, типа пилотов _ТЕСТИРОВАВШИХ_ работу свежепоставленного софта после _ОБСЛУЖИВАНИЯ_ самолета _НА МАЛОЙ ВЫСОТЕ_. Делая _ОПАСНЫЙ МАНЕВР_. И когда stall prevention не сработал, ых, ых, высоты для парирования не хватило. По счастью тестовые пилоты летают без пассажиров, так что куски идиота наказали только себя. Яп опять же в эту формулу не входит.
> Ибо всякому инструменту своё место приложения.
Я прагматик и доверяю только фактам. Полагая что любая теория проверяется практикой. А догмы не ко мне. На практике я вот вижу убившуюся багом ракету. И немеряное количество кода на сях в требовательных применениях.
> MISRA денег стоит и экономии снова не получается. :-)
Есть даже халявные реализации. Ну вот официальных сообщений в них нет, это да.
> И она не поможет в ряде случаев просто в силу специфики языков Си и Си++.
Языки как языки. Если ими не пользоваться как вебмакака, стабильно и надежно сделать можно. А если вебмакачить, то какая разница?
> Я считаю, что если это возможно, то следует избегать их
> использовать в условиях, где отказ компьютерной системы чреват гибелью людей.
А вы много критичных систем такого плана разработали?
> Здесь нет простора для экспериментов по удержанию программеров в тонусе.
Кроме этого логично запускать статические анализаторы и чекеры рулесов. А адовики вон расслабились, срезали угол - и получили фигакс. "Most dangerous time is when you feel yourself safe". За вот это "safe" языки получиют от меня заряд скепсиса. Провоцируют девов на расслабон, а это чревато в ситуации когда надо переиграть весь мир.
> свои коррективы. И поскольку эту особенность из Сей и Плюсов ты
> никуда и никогда не устранишь, то лучше воздерживаться от их использования
> в критически опасных для жизни случаях.
В сях можно использовать статичное распределение памяти. Что MISRA, между прочим, и требует. В этом случае описанная ситуация просто невозможна.
Конечно есть еще пара способов - типа рекурсии, которая в конце концов сожрет стэк, но MISRA и это запрещает. И аналог такого прострела наверное можно сделать на любом развитом ЯП.
Еще на сях достаточно просто контролировать runtime окружение и относительно понятно как это трансформируется на физические дела типа лэйаута бинаря, содержимого оперативы и проч. Это позволяет пытаться относительно осмысленно парировать даже очень странные ситуации типа program counter runaway или сбоев в регистрах.
У STMicro есть годный firmware safety guide на эту тему, рекомендованый автомотивщикам, местами идущий сильно дальше MISRA в некоторых странных вещах - и это касается взаимодействия железа и софта и что делать если "прилетела частица и воткнулась в проц" может реально наделать бед.
> Сколько можно толочь воду в ступе… Это была ошибка человека, а не недостаток языка.
Так основным достоинством заявлено что этого как раз и не будет.
Говоря за себя я фирмвары МК стараюсь писать по примерно таким паттернам:
1) C99 types, вот как раз потому.
2) Нет dynamic memory, так что она не может кончиться.
3) Абсолютный минимум указателей, только если по другому никак.
4) Никакого кода который я не знаю и не понимаю, отвечать за хз что я не готов.
> Они заведомо знали, что делать так нельзя, но они это сделали наперекор судьбе
> и здравому смыслу.
Правда жизни в том что люди иногда ошибаются. Пилоты тестировавшие софт на недостаточной высоте тоже, однако, регламент нарушили. Но жизнь помогла им попасть в эту ситуацию. Так что хотя они и идиоты, к этому были предпосылки навязанные им жизнью.
И таки никто не может бесконечно вылизывать проект. И всегда приходится учитывать фактически доступные ресурсы. Иначе проект будет просто слит. И вообще никогда никуда не полетит. А мудрость гласит что лучше попробовать и обломаться, чем обломаться попробовать.
> Если Маск угробит хотя бы один экипаж живых астронавтов, его путь в
> космос на этом, скорее всего, закончится. Экономия не всегда хороша.
СССР угробил несколько космонавтов. NASA угробило несколько экипажей. Авиаторы потеряли еще больше экипажей. Мы не в детском саду и те кто вписывается в такие миссии прекрасно в курсе что люди не боги - и поэтому всегда есть некоторый риск.
И чисто практически, в случае с ракетой я бы больше всего боялся имхо не программных вещей а все же catastrophic failure на уровне физики. Ну вот стремноватые они в этом по своему устройству, по сравнению с тем же самолетом например. Скажем криогенные дела - "относительно ненадежны".
> ты себе отфигачишь топором какую-нибудь конечность, что никакой вины топора в этом нет.
Да как сказать? Постепенно на циркулярку все же делают защитный кожух а то и вовсе обходятся без контакта опасных объектов с людьми. С космическими кораблями тоже работает - сперва гоняли грузовые версии, как раз посмотреть как оно вообще работает и какие проблемы вылезут.
