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

DOO>Покажи мне хоть одно ТЗ, определяющее функционал АС с точностью до последнего входного сигнала и реакции на него.
АС в данном контексте — аналоговая схема, автоматизированная система, атомная станция, etc?
тз бывают формальными, тз бывают педанитичными. в околоисследовательских задачах тз могут вообще не содержать конкретики. это все понятно. тем не менее, если перед вами лежит тз на разработку нового браузера и в нем (тз) нет раздела про безопасность, включающего защиту от атак, это странно. думаю, любой квалифицированный разработчик не увидев такого пункта, поинтересовался бы причиной его отсутсвия — то ли заказчик забыл, то ли рассчитывет на услугу "все включенно", то ли ему на это вдруг наплевать и он платить за это не будет.

DOO>Честное определение бага было бы что-то вроде — недетерминированность конечного автомата, соответсвующего АС (это более менее понятно, хотя и не совсем верно). Т.е. если программа при получении определенных входных данных или сигнала или еще чего-то попадает в неопределенное разработчиком состояние, то это баг. Даже, если в результате ничего страшного не происходит.

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