>> Если много зависит от окружения, то зачем такая программа нужна вообще? Как ты можешь ей доверять, если она вместо единственно правильного поведения демонстрирует платформо-зависимое?
> Так ведет себя абсолютно весь софт. Дело не в платформе, а в
> окружении.

Нет, не абсолютно. Если софт хочет стабильно парсить ввод, а sscanf на разных платформах ведёт себя по разному, то софт прекращает пользоваться sscanf или таскает с собой свою реализацию sscanf. Если твоя программа считает сумму 2+2 по разному на разных платформах и даёт разные результаты, то твоя программа не нужна.

>> На самом деле не так.
> Да все так. Иначе не было бы тестирования как такового, и не
> было тестов как таковых. И баг, это и есть нарушение когда
> есть определенные входные данные, и результат, выходные данные, не соответствуют ожиданиям.

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

Тестирование -- это лишь одна из методик. И для тестирования тебе не надо разбирать чёрный ящик. Это совершенно не нужно. Более того, я слышал рекомендации писать тесты не зная, как чёрный ящик реализован, потому что знание реализации запросто может привести к тому, что ты будешь делать предположения о том, каких багов нет и быть не может, те же предположения, которые сделал программист, написавший код, который ты пытаешься покрыть тестами. И совершенно все в один голос твердят, что надо по возможности разделять задачи: чтобы код писал один человек, а тестами покрывал другой.

Проверить, приведёт ли x0 в входных данных к y0 в выходных, можно легко засунув x0 в чёрный ящик, и посмотрев, вывалится с другой стороны y0 или y1.

Ты в курсе того, что в gdb добавили "обратную отладку"? То есть возможность проигрывать выполнение процесса назад, шаг за шагом? Как ты думаешь почему? А я скажу тебе: потому что когда ты пытаешься понять, как так в этом месте происходит use-after-free, тебе надо понять кто и когда освободил кусок памяти. Но это произошло когда-то в прошлом, возможно задолго до того момента, когда произошёл use-after-free и твой дебуггер триггернулся.

То есть ты, имея результат работы программы, пытаешься выяснить что привело к такому результату. А для этого тебе нужна обратная функция. То есть обратная отладка.

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

> Ну и с известной функцией проще работать, чем с неизвестной :)

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