Saya melihat publikasi yang telah dipelajari PVS untuk dianalisis di Linux, dan memutuskan untuk mencobanya pada proyek saya sendiri. Dan inilah hasilnya.
kadar
Dukungan responsif
Saya meminta kunci percobaan dan mereka mengirimkannya kepada saya pada hari yang sama.
Dokumentasi yang cukup jelas
Kami berhasil meluncurkan penganalisis tanpa masalah. Bantuan untuk perintah konsol juga tersedia (walaupun ada beberapa keluhan di sini, lihat bagian ).
Kemungkinan analisis multi-utas
Penganalisis memiliki opsi "standar". -j, memungkinkan analisis dilakukan secara paralel dalam beberapa tugas. Ini menghemat banyak waktu.
Visualisasi yang bagus
Banyak format keluaran yang berbeda, dari teks hingga moncong web kecil. .
Integrasi yang mudah ke dalam perakitan
Semua dokumentasi ada di situs web mereka, saya hanya bisa mengatakan bahwa jika proyek Anda dibuat menggunakan CMake, maka semuanya sangat sederhana.
Deskripsi diagnostik yang bagus
Jika Anda menghasilkan output dalam mode fullhtml, maka setiap pesan memiliki link ke deskripsi diagnostik, dengan penjelasan, contoh kode, dan link tambahan.
Ketidaktahuan bahasa C++ oleh penganalisa
Sayangnya, PVS terkadang membuat kesalahan sintaksis dan menghasilkan pesan positif palsu ketika kodenya sepenuhnya benar.
Misalnya ada fungsi yang kembali void:
template <typename T>
auto copy (const void * source, void * destination)
->
std::enable_if_t
<
std::is_copy_constructible<T>::value
>
{
new (destination) T(*static_cast<const T *>(source));
}Ya, kata kunci auto Bisa berarti void, itulah gunanya mobil. Namun PVS menghasilkan pesan-pesan berikut:
dynamic_tuple_management.hpp:29:1: error: V591 Non-void function should return a value.
dynamic_tuple_management.hpp:29:1: error: V2542 Function with a non-void return type should return a value from all exit paths.Situs yang sangat lambat
Ya, di antarmuka web di samping setiap pesan terdapat tautan ke deskripsi diagnostik yang sesuai beserta contohnya. Namun ketika Anda mengklik suatu link, Anda harus menunggu cukup lama, dan terkadang hal itu terjadi .
Bahasa
Semua deskripsi dalam bahasa Rusia, dan itu bagus. Namun link dari laporan selalu mengarah ke versi bahasa Inggris. Alangkah baiknya jika bisa mengganti bahasa sehingga Anda dapat langsung melihat diagnostik dalam bahasa Rusia. Saya tidak menemukan opsi seperti itu di antarmuka.
Tidak nyaman untuk bekerja dengan level diagnostik melalui konsol
Mari kita mulai dengan fakta bahwa dua perintah yang digunakan (ini pvs-studio-analyzer ΠΈ plog-converter) format berbeda untuk menentukan diagnostik.
Membantu untuk pvs-studio-analyzer membaca:
-a [MODE], --analysis-mode [MODE]
MODE defines the type of warnings:
1 - 64-bit errors;
2 - reserved;
4 - General Analysis;
8 - Micro-optimizations;
16 - Customers Specific Requests;
32 - MISRA.
Modes can be combined by adding the values
Default: 4Saya menghabiskan waktu lama mencoba mencari tahu ke mana harus pergi tambah (βmenambahkan nilaiβ) kunci. Saya mencoba membuat daftarnya dipisahkan dengan koma:
pvs-studio-analyzer analyze ... -a 1,4,16Saya mencoba mendaftarkan kunci beberapa kali:
pvs-studio-analyzer analyze ... -a 1 -a 4 -a 16Dan baru pada saat itulah saya menyadari bahwa ini adalah topeng kecil! Dan Anda membutuhkannya menyimpulkanDan tidak tambah makna. Misalnya, untuk mendapatkan diagnostik umum, diagnostik untuk optimasi mikro, dan MISRA, Anda perlu menjumlahkannya (4 + 8 + 32 = 44):
pvs-studio-analyzer analyze ... -a 44Menggunakan bitmask di antarmuka pengguna umumnya merupakan bentuk yang buruk. Semua ini dapat diringkas secara internal, dan serangkaian tanda dapat ditetapkan untuk pengguna.
Selain itu, ada juga utilitasnya plog-converter, yang menghasilkan informasi analisis statis yang dapat dibaca manusia. Dia punya masalah lain.
Bantuan untuk program ini plog-converter laporan:
-a, --analyzer Specifies analyzer(s) and level(s) to be
used for filtering, i.e.
'GA:1,2;64:1;OP:1,2,3;CS:1;MISRA:1,2'
Default: GA:1,2Beberapa "level" muncul di sini yang sebelumnya tidak ada, dan saya juga tidak menemukan apa pun tentangnya di dokumentasi.
Secara umum, tidak jelas. Itu sebabnya saya mengatur semuanya secara maksimal.
Sekelompok orang bodoh yang mengumpat pada Catch
Dua dari tiga proyek yang saya analisis menggunakan perpustakaan pengujian unit . Dan sebagian besar pesan (!!! 90 dari 138 di satu pesan dan 297 dari 344 pesan lainnya!!!) memiliki bentuk berikut:
Tidak memperhitungkan multithreading
Ada banyak kesalahan positif tentang variabel yang dianggap tidak berubah atau loop tanpa akhir, sementara variabel ini bekerja dari thread yang berbeda, dan jika tidak demikian, maka pengujian unit tidak akan berfungsi.
Namun, bisakah penganalisis statis memperhitungkan hal ini? Tidak tahu.
PVS tidak menemukan bug nyata dalam proyek open source saya ΠΈ , serta dalam rancangan kerja, yang karena alasan yang jelas tidak dapat saya sajikan. Benar, perlu diingat bahwa beberapa kekurangan telah ditemukan dan diperbaiki sebelum penggunaan ΠΈ .
Secara umum, kesan dari semua penganalisis ini kurang lebih sama: ya, mereka menangkap sesuatu, terkadang bahkan sesuatu yang penting, tetapi secara umum kompilernya sudah cukup.
Mungkin saja (dan menurut saya pribadi demikian) tim kami menggunakan praktik pengembangan perangkat lunak yang memungkinkan kami menghasilkan kode buruk dalam jumlah minimum. Lebih baik tidak menciptakan masalah daripada mengatasinya dengan gagah berani.
Oleh karena itu, saya memberanikan diri untuk memberikan beberapa saran tentang cara menulis dalam C++ sedemikian rupa agar tidak menembak kaki siapa pun atau memukul dahi siapa pun dengan menyapu.
Manfaatkan diagnostik kompiler semaksimal mungkin
Tim kami menggunakan (dan menyarankan Anda untuk) opsi kompilasi berikut:
-Werror
-Wall
-Wextra
-Wpedantic
-Wcast-align
-Wcast-qual
-Wconversion
-Wctor-dtor-privacy
-Wenum-compare
-Wfloat-equal
-Wnon-virtual-dtor
-Wold-style-cast
-Woverloaded-virtual
-Wredundant-decls
-Wsign-conversion
-Wsign-promoAktifkan mereka dalam proyek Anda dan pelajari banyak tentang kode Anda.
Tetap berpegang pada standar
Cobalah untuk tidak menggunakan hal-hal yang bergantung pada platform jika ada analog standar, dan jika Anda benar-benar tidak dapat melakukannya tanpanya, bungkuslah dalam blok khusus untuk makro (atau yang lainnya) dan jangan biarkan kode Anda dikompilasi dalam kondisi yang tidak didukung.
Tetap berpegang pada semantik operasi standar
Penjumlahan harus penjumlahan, perkalian harus perkalian, pemanggilan fungsi harus pemanggilan fungsi, copy harus copy, carry harus carry, container harus iterable, iterator harus ada promosi ++ dan dereferensi *. Dan seterusnya dan seterusnya.
Saya pikir idenya jelas. Ada konvensi mapan yang tidak mengikat, namun diharapkan dapat dilihat oleh semua pengguna dan pembaca kode Anda. Jangan mencoba mengecoh orang lain, jika tidak, Anda akan mengecoh diri sendiri.
Tulis kode yang kompatibel
Pertama-tama, maksud saya perpustakaan standar. Sangat diharapkan bahwa antarmuka kelas dan fungsi Anda dapat digunakan dengan perpustakaan standar dan lainnya (misalnya, Boost).
Jangan ragu untuk melihat antarmuka STL dan Boost. Dengan pengecualian yang jarang terjadi, Anda akan melihat panutan yang layak di sana.
Manfaatkan alat sumber terbuka semaksimal mungkin
Untuk analisis statis yang sama, setidaknya ada dua alat gratis terbuka yang dapat dihubungkan sekali saja ke proyek apa pun dengan sistem build CMake.
.
Terakhir, saya ingin menekankan bahwa saya tidak menganjurkan untuk tidak menggunakan PVS atau penganalisis statis lainnya. Namun saya mendorong Anda untuk memikirkan bagaimana penganalisis statis terus-menerus menemukan kesalahan signifikan dalam kode Anda.
Ini hanyalah sebuah konsekuensi. Kita perlu mencari dan menghilangkan penyebabnya.
Sumber: www.habr.com