> Вот что значить вот это "Если ты вызываешь из кода php функцию на C"? пхепешный fopen вызывает lib сишный fopen который вызывает системный сишный сискол open.Эмм... Любой язык, кроме ассемблера, становится обёрткой, если следовать такому определению. Си ведь тоже не вызывает напрямую сисколлов, а дёргает обёртки из libc. fopen не вызывает сисколл open напрямую, а дёргает обёртку.
> Лучше сначала определимся и опишем, что требуется от анализатора, ибо будем говорить о разных вещах.
Анализ кода. Как правило с целью найти потенциальные ошибки в коде. Или даже не потенциальные, а самые натуральные ошибки. Когда тебе gcc пишет, что ты в условии if'а использовал =, что скорее всего опечатка, и если ты не хочешь видеть этот варнинг, то он предлагает тебе заключить условие в дополнительные скобки: вот этот варнинг -- как раз работа статического анализатора, встроенного в компилятор. Внешний по отношению к компилятору статический анализатор может выискивать больше подозрительных мест.
Но, в теории, я бы назвал статическим анализатором не только то, что ищет подозрительные места, но например программу, которая, допустим, пытается статическим анализом кода выяснить максимальную глубину стека, которая будет использована. Или, скажем, предсказать где будут бутылочные горлышки производительности. Или, скажем, высчитать максимальный latency наихудшего случая. А в случае, если им не удаётся выполнить свою задачу, то сообщают, что помешало.
Я не упомню таких программ, но исходя из их теоретической возможности: если бы они были, они тоже занимались бы статическим анализом кода, для того, чтобы без запуска программы узнать о ней что-то.
Чтобы понятнее было, можно сравнить с динамическим анализом -- со всякими там профайлерами, valgrind'ами, fuzzing-тестерами, и не только fuzzing, -- которые выясняют что-то о программе, посредством запуска её.
Статический анализ имеет некоторые преимущества: он может формулировать и доказывать утверждения о коде, типа "в этом цикле i всегда будет меньше чем arr.len()", и делать выводы типа
"поэтому проверка условия "i < arr.len()" на каждой итерации цикла не нужна". (ну или ровно наоборот, "WARNING: не удалось доказать, что i<arr.len() следовательно проверка нужна"). В динамике можно лишь статистически проверить такое утверждение, а это совсем не то.
> Если нет возврата управления, то либо "вечный цикл", либо аварийный останов.
while(1) {
exit(0);
}
Вот тебе "вечный" цикл, который прекращает быть вечным (и вообще циклом), если мы знаем, что exit -- это no-return функция. Если тебе хочется более реалистичного примера, то...
for(i = 0; ; i++) {
if(fds[i] >= 0)
close(fds[i]);
else
exit(0);
}
Код закрывает все fds, из предположения что все открытые файловые дескрипторы лежат в начале fds, а все неиспользуемые элементы fds < 0, и что как минимум один неиспользуемый там есть. Он закрывает все, и завершает выполнение программы. Если мы не знаем, что exit завершает выполнение программы, то внезапно мы видим вечный цикл, который рано или поздно выйдет за границы массива, либо потому что i станет слишком большим, либо потому, что случится переполнение целого и i станет слишком отрицательным.
Хотя статистическому анализатору это всё равно, не поможет, потому как он не знает про инварианты fds, но мне не придумать сходу ещё более реалистичного примера. А! Можно анализатору подсунуть инварианты fds в виде логических утверждений, и пускай после этого он проверяет их соблюдение, и правильное использование fds тоже проверяет. А когда не может проверить, пускай кидает варнинги, мы будем править код, так, чтобы анализатор справился бы с доказательством.
Впрочем, в php, я подозреваю всё проще. Я думаю, тут не случайно так совпало, что в одном релизе появились и fiber'ы, и noreturn функции: fiber'ы постоянно завершаются. Программа завершается лишь раз, за всё время работы, а fiber'ов много, и почти все они завершаются. И тут, я полагаю, требуется определённое взаимодействие рантайма (который рулит фиберами) и компилятора, чтобы компилятор no-return функции правильно бы норетурнил, прибивая фибер. Ну или что-нибудь в этом роде.
> Что он будет выдавать, когда столкнется с проблемой останова? Статический анализатор ведь должен простроить граф потока управления.
А где там проблема останова вылезет? Как я это вижу, если компилятор может проследить пути выполнения таким образом, чтобы разложить код в линейную последовательность ассемблерных инструкций, или операций интерпретатора, то значит он может определить моменты, где происходит возврат из функции, а возвращаемое значение не предоставлено, так? А если компилятор может, то и статический анализатор сможет. Особенно если он -- часть компилятора.
А ежели компилятор этого не может сделать, то значит он не может завершить компиляцию разумным образом, и значит это ошибка компилятора. То есть в результате статистического анализа в программе была найдена ошибка.
> А как анализатор это может разрешить, что удалить, ошибочно добавленный exit или анюзед код после него. Это решает программист. А анализатор должен сообщить лишь о том, что у тебе тут exit, а код ниже никогда не исполниьтся.
Да, именно так он и делает, он кидает варнинги. Но для того, чтобы решить, что здесь нужно кинуть варнинг, он сначала должен детектировать код, который не будет выполняться никогда. А для этого ему надо знать, что exit -- это no-return функция.
