LINUX.ORG.RU

Статический анализ C++ кода на специфическое приведение типов (unsigned в long)

 


0

3

Такая проблема, в связи с портированием некоего win кода на linux, нужно отследить приведения unsigned к long (под x86_64).

Может какой-нибудь статический анализатор в этом помочь?

★★★★★

да постигнет же анальная кара неиспользующих <stdint.h>

(сори, помочь нечем)

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

Ещё ничего не пробовал, спрашиваю что попробовать. Спасибо, посмотрю.

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

бро

Собственно, scan-build мне побоку, нужен clang-analyzer.

таки прочитай как работает скан-билд (там совсем немного), и твои волосы (скорее всего) станут мягкими и далее-по-тексту

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

чесно - не помню, но 90%, что есть (ибо это частые грабли)

Stil ★★★★★
()

Вроде ж в студии есть фича проверки кода на x86_64 совместимость. Тебе она не подходит?

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

В винде int и long одного размера, разве там сработает какая-то проверка? Надо попробовать...

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

Она нужна только при компиляции 32-битного кода, а если он собирается 64-битный то и так всё студия сообщит. Про long->unsigned оно не сообщит т.к. long в винде 32-битный, проблем нет.

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

А проекту 15 лет, а привычкам win программистов ещё больше...

В 2010 точно есть. В 2008 ЕМНИП тоже есть.

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

А вывернуться с временной заменой не выйдет?

Типа заменить везде unsigned long на uint64_t, long на int64_t и попробовать собрать.

Pavval ★★★★★
()

мне в подобных случаях помогает условно-бесплатная обертка над clang, http://sci-tools.com/

у них есть свой анализатор (можно выбрать), но clang гораздо лучше работает.

там достаточно простое api для си, питона и перла, которым можно походить по деревяшке, посмотреть типы и т.д.

что-то вроде требуемого у меня написалось в пару строчек перлового кода.

сейчас у них ещё стало много своих проверок, так что может такая и есть, но по-моему проще самому написать.

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

Ну там 10 миллионов строк кода. Сложновато будет :-) Потом, меня не интересуют все проблемы, а только конкретный каст.

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

на всякий случай, у gcc есть -Wold-style-cast.

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

Про sed выше уже сказали. Попробуй - будет много траха с разбором ошибок, но в конце концов все касты найдешь.

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

Дык менять-то надо ULONG/LONG, LONG64, и т.п. «long long». «long double». Не менять там, где вызываются функции, принимающие long* или long&. Короче не выйдет малахитова шкатулка. Была идея с #define long int но проблем много.

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

PVS-Studio

То, что Вам нужно, называется статический анализатор PVS-Studio. В нем мощная система диагностики 64-битных дефектов. Даже через чур мощная, из-за чего имеется масса ложных срабатываний. Но лишние диагностики легко отключаются.

Попробовать: http://www.viva64.com/ru/pvs-studio/

Если проекта для VS нет, то Вам поможет Standalone вариант - http://www.viva64.com/ru/b/0219/

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

Проект же должен clang-ом собираться, правильно? Увы.

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