Какие уровни должны анализировать статические анализаторы?

Эти различные аспекты могут влиять на уровень, на котором анализатор может решить работать:

1. Разработка статического анализатора - это много работы. Было бы стыдно не учитывать эту работу для нескольких языков, скомпилированных в один и тот же байт-код, особенно когда байт-код сохраняет большую часть структуры исходной программы: Java (FindBugs), .NET (различные инструменты связанных с Кодовыми контрактами). В некоторых случаях общий целевой язык был создан с целью анализа, хотя схема компиляции не соответствовала этот путь.

2. Что касается 1, вы можете надеяться, что ваш статический анализатор будет немного дешевле писать, если он будет работать с нормализованной версией программы с минимальным количеством конструкций. При создании статических анализаторов необходимость писать лечение для repeat until, когда вы уже написали while do, вызывает затруднения. Вы можете структурировать свой анализатор так, чтобы несколько функций были общими для этих двух случаев, но самый простой способ справиться с этим - перевести одну в другую или перевести исходный текст на промежуточный язык, который имеет только один из них.

3. С другой стороны, как уже указывалось в ответе Flash Sheridan, исходный код содержит больше всего информации. Например, в языках с нечеткой семантикой ошибки на уровне исходного кода могут быть удалены путем компиляции. C и C ++ имеют множество «неопределенных поведений», когда компилятору разрешено делать что угодно, включая создание программы, которая работает случайно. Вы можете подумать, что если ошибки нет в исполняемом файле, это не проблема. Но когда вы когда-нибудь перекомпилируете программу для другой архитектуры или со следующей версией компилятора, ошибка может появиться снова. Это одна из причин, по которой не следует проводить анализ после любого этапа, который потенциально может удалить ошибки.

4. Некоторые свойства можно проверить с разумной точностью только в скомпилированном коде. Это включает в себя отсутствие ошибок, вносимых компилятором, как снова указал Flash Sheridan, но также и наихудшее время выполнения. Точно так же многие языки не сообщают вам, что именно делает код с плавающей запятой, если вы не посмотрите на сборку, сгенерированную компилятором (это потому, что существующее оборудование не позволяет им гарантировать больше). В таком случае выбор состоит в том, чтобы написать неточный анализатор уровня исходного кода, который учитывает все возможности, или проанализировать только одну конкретную компиляцию программы с плавающей запятой, если предполагается, что именно этот точный ассемблерный код будет выполняться. .

Анализ исходного кода, конечно, наиболее полезен; иногда эвристикам даже требуется анализировать комментарии или форматирование. Но вы правы в том, что может потребоваться даже анализ объектного кода, например, для обнаружения ошибок, внесенных Недостатки GCC. Томас Репс, глава GrammaTech и профессор из Висконсина, пару лет назад подробно рассказал об этом в Стэнфорде: http://pages.cs.wisc.edu/~reps/#TOPLAS-WYSINWYX.