чем этот велосипед лучше FindBugs ?

ymn ★★★★★  А ты у мамы хакир?

сам-то юзал? как оно?

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

• работает не только с джавой;
• работает не с байткодом, а с исходным кодом

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

сам-то юзал?

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

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

Infer написан на языке OCaml

расскажите, что такое окамл

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

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

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

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

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

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

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

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

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.

А чего ж не на коке?

Лучше писать на окамле, чем писать на сишке и проверять её кодом на окамле.

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

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

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

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

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

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

ололо

Лучше писать на окамле, чем писать на сишке и проверять её кодом на окамле.

кому лучше?

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

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

и это все

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

Всем.

Что именно тебя смущает?

False много, можно было обойтись одним последним.

Офигенно же

Надеюсь, объединят усилия с Frama-C.

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

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

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

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

10/10

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

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

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

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

Любопытно, натравлю на android проект. Спасибо за новость.

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

Это настоящие ошибки? Не ложные срабатывания?

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

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

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

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

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

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

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

Не знаю, как для c, но для Java мало что находит. Не больше, чем анализатор из idea.

To run Infer you will need Python 2.7

Catch-all case — это плохой стиль.

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

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

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

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

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

Для java может и полезно, но для С valgrind как-то привычнее.

valgrind делает статический анализ?

Для статического юзаю обычно cppcheck.

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

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

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

Ещё есть

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

cppcheck

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

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

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