Собственно, краткое описание со ссылками на литературу содержится по следующей ссылке:
On Curiosity and its software Getting 2.5 Megalines of code to behave

Наибольший интерес, пожалуй, представляют ссылки на источники в конце статьи.

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

еще одно интересное на тему:
The Remote Agent Experiment: Debugging Code from 60 Million Miles Away

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

Еще одна статья на эту же тему
NASA’s 10 rules for developing safety-critical code

NASA’s been writing mission-critical software for space exploration for decades, and now the organization is turning those guidelines into a coding standard for the software development industry.

Read more: http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/#ixzz3OJYfNwug
Follow us: @sdtimes on Twitter | sdtimes on Facebook

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

BE>Собственно, краткое описание со ссылками на литературу содержится по следующей ссылке:
BE>On Curiosity and its software Getting 2.5 Megalines of code to behave

BE>Наибольший интерес, пожалуй, представляют ссылки на источники в конце статьи.

Прикольно. Оттуда:

The rule of zero warnings applies even in cases where the compiler or the static analyzer gives an erroneous warning. If the compiler or the static analyzer gets confused, the code causing the confusion should be rewritten so that it becomes more clearly valid

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

AD>Прикольно. Оттуда:
AD>

AD>The rule of zero warnings applies even in cases where the compiler or the static analyzer gives an erroneous warning. If the compiler or the static analyzer gets confused, the code causing the confusion should be rewritten so that it becomes more clearly valid

Это правильно, т.к. цена ошибки может измеряться в миллиардах.

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

BE>Собственно, краткое описание со ссылками на литературу содержится по следующей ссылке:
BE>On Curiosity and its software Getting 2.5 Megalines of code to behave

BE>Наибольший интерес, пожалуй, представляют ссылки на источники в конце статьи.

Супер. Интересно, каким образом они доказывали отсутствие дедлоков — ведь в ПО больше сотни потоков.


Update. Сам нашел:

The use of semaphores or locks to access shared data should be avoided (cf. Rules 6 and 8). If used, nested use of semaphores or locks should be avoided. If such use is unavoidable, calls shall always occur in a single predetermined, and documented, order.

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

BE>Еще одна статья на эту же тему
BE>NASA’s 10 rules for developing safety-critical code

BE>

NASA’s been writing mission-critical software for space exploration for decades, and now the organization is turning those guidelines into a coding standard for the software development industry.

BE>Read more: http://sdtimes.com/nasas-10-rules-developing-safety-critical-code/#ixzz3OJYfNwug
BE>Follow us: @sdtimes on Twitter | sdtimes on Facebook

Со всем согласен, кроме п. 9, его, скорее всего, не понял. Чем им не угодили многоуровневые разыменования? Ни разу в жизни не видел, чтоб это приводило к проблемам. Что вообще имеется в виду? Не писать **ppUnk? По-моему, компилятор с системой типов достаточно надежно проверяет, что лишних * или & нет.

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

BDA>Со всем согласен, кроме п. 9, его, скорее всего, не понял. Чем им не угодили многоуровневые разыменования?

Код становится слишком сложным и запутанным для mission-critical приложений. Валиден он или нет — вообще дело десятое.

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

BDA>Со всем согласен, кроме п. 9, его, скорее всего, не понял. Чем им не угодили многоуровневые разыменования? Ни разу в жизни не видел, чтоб это приводило к проблемам. Что вообще имеется в виду? Не писать **ppUnk? По-моему, компилятор с системой типов достаточно надежно проверяет, что лишних * или & нет.

Читать сложно. И не факт что где-то звездочка не потеряется в итоге.