> Эмм... Любой язык, кроме ассемблера, становится обёрткой, если следовать такому определению.
> Си ведь тоже не вызывает напрямую сисколлов, а дёргает обёртки из
> libc. fopen не вызывает сисколл open напрямую, а дёргает обёртку.

Ну да.

> Анализ кода. Как правило с целью найти потенциальные ошибки в коде. Или
> даже не потенциальные, а самые натуральные ошибки.

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

1) Анализ кода с точки зрения безопасности алгоритма. (???????? тут много вопросов)

2) Анализ кода с точки зрения корректности алгоритма. (работа алгоритма выдает желаемый результат, при описанных условиях)

3) Анализ кода с точки зрения оптимальности алгоритма. (тут имеется ввиду не то, что анализатор увидев алгоритм сортировки "пузырьком" выдавал предупреждение, мол можно использовать квиксорт, а оптимальное использование как временных (быстродействие), так и пространственных ресурсов (использование памяти))

Хотя предположу, тот же анализ безопасности вытекает из корректности и оптимальности алгоритма. Думаю на текущий момент любую проблему (ошибку) безопасности можно свести к корректности и оптимальности. Алгоритм "безопасный", если он "корректный" и "оптимальный".

Далее про "самые натуральные ошибки" ( :), не мог себе представить какую из ошибок могу считать натуральной, ошибки за которые учительница по рукам линейкой бьет?), так вот надо понять какие "ошибки" имеем ввиду.

1) Синтаксические, грамматические, лексические - приводящие к некорректности алгоритма.

2) Логические - приводящие как к некорректности, так и к неоптимальности.  

Что тут еще добавить?

> Когда тебе gcc пишет,
> что ты в условии if'а использовал =, что скорее всего опечатка,
> и если ты не хочешь видеть этот варнинг, то он предлагает
> тебе заключить условие в дополнительные скобки: вот этот варнинг -- как
> раз работа статического анализатора, встроенного в компилятор.

А зачем тут ворнинг? какой в этом смысл, если реально мне не запрещает ЯП использовать в if присваивание =. Ибо результат этого присваивания тем же ЯП будет трактоваться как булево (логическое) значение, а оператор if именно с такими значениями (операндами) работает. Да конечно в большинстве случаев это "банальная" логическая ошибка, но ни как не синтаксическая, грамматическая, лексическая. И решение этой проблемы, в  синтаксическом переосмыслении условного оператора. Зачем компилятору ворнинг, если конкретно эта ситуация допустима в ЯП?

> Внешний по отношению к
> компилятору статический анализатор может выискивать больше подозрительных мест.

Только если он будет следовать каким-то заранее заданным шаблонам (паттернам логических ошибок), ибо не существует анализатора который бы разрешил бы проблему останова, так как это проблема банальный логический парадокс. Если человеческая логика впадает в ступор перед логическими парадоксами, думаете анализатор с ними справится (можно на это не отвечать)?

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

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

> Я не упомню таких программ, но исходя из их теоретической возможности: если
> бы они были, они тоже занимались бы статическим анализом кода, для
> того, чтобы без запуска программы узнать о ней что-то.

Как выше написал, как без запуска программы сравнить ее результат с ожидаемым?

> Чтобы понятнее было, можно сравнить с динамическим анализом -- со всякими там
> профайлерами, valgrind'ами, fuzzing-тестерами, и не только fuzzing, -- которые выясняют
> что-то о программе, посредством запуска её.
> Статический анализ имеет некоторые преимущества: он может формулировать и доказывать утверждения
> о коде, типа "в этом цикле i всегда будет меньше чем
> arr.len()", и делать выводы типа
> "поэтому проверка условия "i < arr.len()" на каждой итерации цикла не нужна".
> (ну или ровно наоборот, "WARNING: не удалось доказать, что i<arr.len() следовательно
> проверка нужна"). В динамике можно лишь статистически проверить такое утверждение, а
> это совсем не то.

Вот тут немного не ясно, хочу увидеть всю конструкцию цикла, не могу представить.

>[оверквотинг удален]
>     else
>         exit(0);
> }
> Код закрывает все fds, из предположения что все открытые файловые дескрипторы лежат
> в начале fds, а все неиспользуемые элементы fds < 0, и
> что как минимум один неиспользуемый там есть. Он закрывает все, и
> завершает выполнение программы. Если мы не знаем, что exit завершает выполнение
> программы, то внезапно мы видим вечный цикл, который рано или поздно
> выйдет за границы массива, либо потому что i станет слишком большим,
> либо потому, что случится переполнение целого и i станет слишком отрицательным.

Смотрите, что такое тип ? - область (диапазон) допустимых значений, из примера выше переменная i имеет тип целочисленного значения (не важно пока со знаком или без) и инкрементируется в бесконечном цикле. Отсюда делаем вывод, что переменная i в данном случае может принять все допустимые значения (допустим MAX_UINT). Далее эта переменная используется в качестве индекса массива fds, размер (длина) которого не превышает MAX_UINT по определению, что индексация массивов находится в области допустимых целочисленных значений без знака. Но если мы обращаемся по индексу, который больше размера (длины) массива, то происходит аварийный останов, из-за выхода за границы массива. Собственно вопрос, как в случае когда размер (длина) массива заранее не известна, статический анализатор скажет (без исполнения), мол тут выход за границы массива? А выход из цикла разве не будет если допустим что аварийного останова нет и после переполнения инта он становится обратно в 0, то по условию это уже освобожденный файловый дескриптор и выполниться exit().

> Хотя статистическому анализатору это всё равно, не поможет, потому как он не
> знает про инварианты fds, но мне не придумать сходу ещё более
> реалистичного примера.

Таки да.

> А! Можно анализатору подсунуть инварианты fds в виде логических
> утверждений, и пускай после этого он проверяет их соблюдение, и правильное
> использование fds тоже проверяет. А когда не может проверить, пускай кидает
> варнинги, мы будем править код, так, чтобы анализатор справился бы с
> доказательством.

А не легче сильно статически это определять? Вспомним язык паскаль, и мнение Кернигана о нем (Почему Паскаль не является моим любимым языком программирования). Помните, мы обсуждали строки сишные и паскалевы их плюсы и минусы, тоже самое и с анализаторами Вывод мой таков, статический анализатор применим в основном в сильно статических (система типов) ЯП, а для "динамических" - динамический анализатор. Не вижу смысла статическим анализатором пытаться анализировать код динамического ЯП. Кстати про no-return функции, что нам предоставляет паскаль? - процедуры (которые ничего не возвращают) и собственно функции. Статический анализатор способен в таком случае распознать no-return "функцию"? А в С что? оператор return. А если его нет?

https://stackoverflow.com/questions/4260048/c-function-defin...

https://stackoverflow.com/questions/45981545/why-does-noretu...

> А где там проблема останова вылезет? Как я это вижу, если компилятор
> может проследить пути выполнения таким образом, чтобы разложить код в линейную
> последовательность ассемблерных инструкций, или операций интерпретатора, то значит он
> может определить моменты, где происходит возврат из функции, а возвращаемое значение
> не предоставлено, так? А если компилятор может, то и статический анализатор
> сможет. Особенно если он -- часть компилятора.

Стоп, стоп, тут не надо путать понятия компиляции с понятием исполнения, компилятор не исполняет!

Ибо как вы представляете себе компиляцию такой программы?

while (true)
{
   [code block] - а тут нет никакой функции или оператора прерывающий цикл.
}

Тоже самое с unused кодом, во многих случаях ни компилятор ни статический анализатор не сможет принять решение является ли код не используемым, исключая некоторые частные случаи, как отметил выше, паттерны заложенные в анализатор или компилятор.

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

нет, нет - процесс компиляции и непосредственного выполнения - разные понятия.

> Да, именно так он и делает, он кидает варнинги. Но для того,
> чтобы решить, что здесь нужно кинуть варнинг, он сначала должен детектировать
> код, который не будет выполняться никогда. А для этого ему надо
> знать, что exit -- это no-return функция.

И детектирует только по заранее известному паттерну, то есть вы должны создать статический анализатор все-возможного говно-кода (грубо говоря). Статический анализатор это не симулятор исполнения, тогда ему необходимы входные данные, а если ему эти данные дать, то это динамический анализатор. Надо просто четко знать какие задачи выполнимы статическим анализатором.