LINUX.ORG.RU

Открыт исходный код статического анализатора Infer

 , ,


3

4

Компания Facebook опубликовала исходные коды статического анализатора Infer, который используется внутри компании для выявления ошибок в исходном коде программ без их непосредственного запуска.

В настоящее время Infer умеет обнаруживать следующие проблемы в программах, написанных на C, Java и Objective-C:

  • разыменование NULL-указателей;
  • утечки памяти и ресурсов.

Исходный код Infer написан на языке OCaml и распространяется на условиях лицензии BSD.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: CYB3R (всего исправлений: 3)

мининовость, не больше

anonymous
()
Ответ на: комментарий от Deleted
  • работает не только с джавой;
  • работает не с байткодом, а с исходным кодом

Это не лучше или хуже, это еще один дополнительный инструмент.

ymn ★★★★★
() автор топика
Ответ на: комментарий от reprimand

сам-то юзал?

К сожалению, не пишу ни на одном языке, который эта штука умеет анализировать.

ymn ★★★★★
() автор топика

Про «детектировать» сейчас скажут.

Jayrome ★★★★★
()
Ответ на: комментарий от ymn

Это не лучше или хуже, это еще один дополнительный инструмент.

Очередной блокнот это признак NIH, тем более который ничего не умеет.

Deleted
()

Infer написан на языке OCaml
умеет детектировать проблемы в программах, написанных на Objective-C, Java и C

Прекрасно. Это означает, что в ближайшее время к проекту могут присоединиться чуть более чем 0 программистов. Так держать! Больше программ на птичих языках в массы!

asaw ★★★★★
()
Ответ на: комментарий от Deleted

Очередной блокнот

А что еще есть? Накидай ссылок.

тем более который ничего не умеет

эээ, пишут что

We use Facebook Infer internally to analyze the main Facebook apps for Android and iOS (used by more than a billion people), Facebook Messenger, and Instagram, among others.

ymn ★★★★★
() автор топика
Ответ на: комментарий от ymn

А что еще есть? Накидай ссылок.

Первый пост в сем топике.

эээ, пишут что
разыменование NULL-указателей;
утечки памяти и ресурсов.

Пофиксил, и это все. Щас даже netbeans научился детектить эти примитивные случаи.

Deleted
()

Открыл первый попавшийся исходник

let get_forall = function
  | Condition_redundant _ -> true
  | Field_not_initialized _ -> false
  | Field_not_mutable _ -> false
  | Field_annotation_inconsistent _ -> false
  | Field_over_annotated _ -> false
  | Inconsistent_subclass_return_annotation _ -> false
  | Inconsistent_subclass_parameter_annotation _ -> false
  | Null_field_access _ -> false
  | Call_receiver_annotation_inconsistent _ -> false
  | Parameter_annotation_inconsistent _ -> false
  | Return_annotation_inconsistent _ -> false
  | Return_over_annotated _ -> false

ололо

olibjerd ★★★★★
()
Ответ на: комментарий от Deleted

Первый пост в сем топике

Оно же только для джавы, не?

и это все

Пока всё, да. Ждем ебилдов.

ymn ★★★★★
() автор топика
Ответ на: комментарий от ymn

C и Objective C тоже поддерживаются. Вот пример вывода для radare2:

libr/anal/p/anal_gb.c:626: error: NULL_DEREFERENCE
   pointer op->dst last assigned on line 623 could be null and is dereferenced at line 626, column 2

libr/anal/p/anal_java.c:416: error: NULL_DEREFERENCE
   pointer paddr64 last assigned on line 415 could be null and is dereferenced at line 416, column 4

libr/anal/p/anal_java.c:418: error: MEMORY_LEAK
   memory dynamically allocated to paddr64 by call to malloc() at line 415, column 14 is not reachable after line 418, column 4

libr/anal/p/anal_java.c:423: error: NULL_DEREFERENCE
   pointer paddr64 last assigned on line 422 could be null and is dereferenced at line 423, column 4

libr/anal/p/anal_java.c:425: error: MEMORY_LEAK
   memory dynamically allocated to paddr64 by call to malloc() at line 422, column 14 is not reachable after line 425, column 4

libr/anal/p/anal_java.c:427: error: NULL_DEREFERENCE
   pointer paddr64 last assigned on line 426 could be null and is dereferenced at line 427, column 4

libr/anal/p/anal_sh.c:209: error: NULL_DEREFERENCE
   pointer ret last assigned on line 208 could be null and is dereferenced at line 209, column 9

libr/anal/p/anal_sh.c:215: error: NULL_DEREFERENCE
   pointer ret last assigned on line 214 could be null and is dereferenced at line 215, column 9

XVilka ★★★★★
()

We provide pre-built binaries for Infer. Currently, only Mac OS X and Linux 64 bits are supported

Все правильно. Нечего поддерживать маргинальные ОС, типа Windows.

mono ★★★★★
()

Не особо знаком с жабой/си, но 2 типа ошибок кажется как-то мало. Или там 90% ошибок такие?

Klymedy ★★★★★
()

Более того, сами алгоритмы основаны на separation logic, что является более практичным для верификации расширением логики Хоара, так что в перспективе, при должном развитии, этот анализатор может составить конкуренцию Coverity.

XVilka ★★★★★
()

Это «выявление» сродни warnings - да-да, те самые, на которые программисты после второго десятка предупреждений перестают обращать внимания вообще. :)

А зачем использовать такой малораспространённый язык? Их «айти босс» не догадывается, что унификация инструментов - это большой плюс ВСЕЙ компании? Или они думают, что налепив веб-сервисов, можно интегрировать любое г-но? Так дело не только в интеграции, но и в сотрудниках, обучении, зрелости инструментов и т.п. Я это к чему... у них же был какой-то проект на Ди - «сам Александреску» даже писал! Почему бы _промышленный_ язык не продвигать для всех этих анал-лизаторов? Ди как язык устранил сотни проблем, мешающих надёжности С/С++ кода. И странно, все ходят с таким умным е***ом, будто надёжность никому не нужна! Но стоит спросить об этом, как тут же выкатывается простыня «защитных мер», половину которых можно просто даже не применять, ибо за вас это сделает сам Ди. Вот чудаки!...

matumba ★★★★★
()
Ответ на: комментарий от Deleted

Тем что умеет С. И ловит утечки памяти в Java коде, lol.

A-234 ★★★★★
()
Ответ на: комментарий от ymn

для остальных языков есть другие инструменты

Deleted
()
Ответ на: комментарий от matumba

А зачем использовать такой малораспространённый язык?

Потому что он позволяет сделать работу быстрее, чем любой другой // К.О.

tailgunner ★★★★★
()
Ответ на: комментарий от mono

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

misterious
()
Ответ на: комментарий от asaw

Java и C
чуть более чем 0 программистов
программ на птичих языках

Ты и правда очень толстая рыбка.

anonymous
()
Ответ на: комментарий от matumba

AFAIK в Facebook никто особо не контролирует используемые языки/технологии - что разработчики конкретного продукта/сервиса хотят, то и идёт в ход.

Dicebot
()

Вот, умеет только це, жаву, и обж-це. А цепепе не умеет, что, как бы, намекает :-)

anonymous
()

To run Infer you will need Python 2.7

anonymous
()
Ответ на: комментарий от matumba

унификация инструментов - это большой плюс ВСЕЙ компании?

Чо, правда? А может, плюс — это использование инструментов там, где они подходят?

Miguel ★★★★★
()

А нужно ли? Стандартные IDE умеют всё это делать

GblGbl ★★★★★
()
Ответ на: комментарий от anonymous

Еще не успели проверить, но, похожи на настоящие.

Посмотрел, правда сам код Infer - ему еще расти и расти, даже странно, что с 2013 года он не сильно развился.

XVilka ★★★★★
()
Ответ на: комментарий от ncrmnt

cppcheck-у далеко до тех математических методов, использованных в infer. Я надеюсь, что сообщество подхватит этот инструмент, так как большинство аналогов - платные, и, как правило, дорогие.

Мы в radare2 используем как Coverity, так и valgrind, особенно поверх набора тестов. Оба находят независимо друг от друга большое количество ошибок. Ну а также ASAN/UBSAN из clang/gcc.

XVilka ★★★★★
()
Последнее исправление: XVilka (всего исправлений: 1)
Ответ на: комментарий от XVilka

Я в парочке проектов своих юзаю обычно valgrind поверх набора тестов и cppcheck. Coverity не пробовал. Сейчас вот infer заодно добавлю - посмотрим разницу.

ncrmnt ★★★★★
()
Ответ на: комментарий от XVilka

Прогнал мелкий проектик свой (pure C) http://github.com/nekromant/aura через cppcheck и infer.

cppcheck нашел очевидный memory-leak в недописанном и нерабочем transport-serial.c, пачку стилистических мест, где можно уменьшить скоуп переменных. infer - только один __attribute__((packed)) в неположенном месте. В общем как-то пока впечатление не очень. Надо будет покурить какие там у него флажки есть.

ncrmnt ★★★★★
()

Открыт код ненужно, написанного на ненужно для ненужно, от ненужной компании.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.