Pinout afișaj LCD. Obțineți un ecran: propriul ecran TFT. Un exemplu de schiță pentru lucrul cu butoanele ecranului și meniului

Puteți vizualiza articolul original folosind Wayback Machine - Internet Archive: Static Code Analysis.

Deoarece toate articolele de pe site-ul nostru sunt prezentate în rusă și engleză, am tradus articolul Analiza codului static în rusă. Și în același timp am decis să-l publicăm pe Habré. O repovestire a acestui articol a fost deja publicată aici. Dar sunt sigur că mulți vor fi interesați să citească traducerea.

Consider că cea mai importantă realizare a mea ca programator din ultimii ani este cunoștințele mele cu tehnica analizei statice a codului și utilizarea activă a acesteia. Nu este vorba atât de sutele de erori grave care au fost ținute în afara codului datorită acestuia, ci de schimbarea cauzată de această experiență în viziunea mea despre programare în ceea ce privește problemele de fiabilitate și calitate a software-ului.

Trebuie remarcat imediat că totul nu poate fi redus la calitate, iar a admite acest lucru nu înseamnă deloc a trăda niciunul dintre principiile tale morale. Valoare are produsul pe care îl creați ca întreg, iar calitatea codului este doar una dintre componentele sale, împreună cu costul, funcționalitatea și alte caracteristici. Lumea cunoaște multe proiecte de joc super-reușite și respectate, pline de bug-uri și care se prăbușesc în mod constant; și ar fi o prostie să abordezi scrierea unui joc cu aceeași seriozitate cu care creează software pentru naveta spațială. Cu toate acestea, calitatea este, fără îndoială, o componentă importantă.

Mereu am încercat să scriu cod bun. Din fire, sunt ca un meșter, mânat de dorința de a îmbunătăți continuu ceva. Am citit mormane de cărți cu titluri plictisitoare de capitole, cum ar fi „Strategii, standarde și planuri de calitate”, iar lucrul la Armadillo Aerospace m-a introdus într-o lume complet diferită a dezvoltării de software intensivă în securitate față de experiența mea anterioară.

Acum mai bine de zece ani, când dezvoltam Quake 3, am cumpărat o licență pentru PC-Lint și am încercat să o folosesc în munca mea: am fost atras de ideea detectării automate a defectelor în cod. Cu toate acestea, nevoia de a rula din linia de comandă și de a vedea liste lungi de mesaje de diagnosticare m-a descurajat să folosesc instrumentul și l-am abandonat curând.

De atunci, atât numărul de programatori, cât și dimensiunea bazei de cod au crescut cu un ordin de mărime, iar accentul în programare s-a mutat de la C la C++. Toate acestea au pregătit un teren mult mai fertil pentru erorile software. În urmă cu câțiva ani, după ce am citit o selecție de articole științifice despre analiza codului static modern, am decis să verific cum s-au schimbat lucrurile în acest domeniu în ultimii zece ani de când am încercat să lucrez cu PC-Lint.

La acel moment, codul nostru a fost compilat la nivelul de avertizare 4 și am lăsat dezactivate doar câteva diagnostice foarte specializate. Cu această abordare - tratând cu bună știință fiecare avertisment ca pe o eroare - programatorii au fost forțați să adere cu strictețe la această politică. Și deși în codul nostru găseai câteva colțuri prăfuite în care se adunaseră tot felul de „gunoaie” de-a lungul anilor, per total era destul de modern. Ne-am gândit că avem o bază de cod destul de bună.

Acoperire

Totul a început când am contactat Coverity și m-am înscris pentru un diagnostic de probă a codului nostru cu instrumentul lor. Acesta este un program serios, costul licenței depinde de numărul total de linii de cod și ne-am stabilit pe un preț exprimat în cinci cifre. Când ne-au arătat rezultatele analizei, experții de la Coverity au remarcat că baza noastră de date era una dintre cele mai curate din „clasa de greutate” pe care le-au văzut vreodată (poate spun asta tuturor clienților pentru a-i liniști), dar raportul că ei Ne-a fost înmânat și conținea aproximativ o sută de zone cu probleme. Această abordare a fost foarte diferită de experiența mea anterioară cu PC-Lint. Raportul semnal-zgomot în acest caz a fost extrem de ridicat: majoritatea avertismentelor emise de Coverity au indicat de fapt secțiuni de cod clar incorecte care ar putea avea consecințe grave.

Acest incident mi-a deschis literalmente ochii asupra analizei statice, dar prețul mare al tuturor distracției m-a împiedicat să cumpăr instrumentul pentru ceva timp. Ne-am gândit că în codul rămas înainte de lansare nu vom avea multe erori.

Microsoft /analiza

Este posibil să mă hotărăsc în cele din urmă să cumpăr Coverity, dar în timp ce mă gândeam la asta, Microsoft a pus capăt îndoielilor mele prin implementarea unei noi funcții /analiza în SDK-ul 360 ​​. /Analyze a fost disponibil anterior ca o componentă a versiunii de vârf, nebun de costisitoare a Visual Studio, iar apoi, brusc, a fost oferit gratuit fiecărui dezvoltator de pe Xbox 360. După cum am înțeles, Microsoft îi pasă mai mult de calitatea jocurilor de pe platforma 360 ​​decât despre calitatea software-ului pe Windows. :-)

Din punct de vedere tehnic, analizorul Microsoft efectuează doar analize locale, adică. este inferior analizei globale a Coverity, dar când am pornit-o, a eșuat munţi mesaje - mult mai mult decât a emis Coverity. Da, au existat o mulțime de fals pozitive, dar chiar și fără ele au existat o mulțime de bug-uri înfricoșătoare, cu adevărat înfiorătoare.

Am început încet să editez codul - în primul rând, am lucrat pe cont propriu, apoi pe cel de sistem și în sfârșit pe cel de joc. A trebuit să lucrez în ritmuri și starturi în timpul liber, așa că întregul proces a durat câteva luni. Totuși, această întârziere a avut și un efect secundar benefic: am verificat că /analyze a prins de fapt defecte importante. Cert este că, simultan cu editările mele, dezvoltatorii noștri au efectuat o vânătoare mare de erori de mai multe zile și s-a dovedit că de fiecare dată au atacat urma unei erori care fusese deja marcată/analiza, dar nu fusese încă fixat de mine. Pe lângă aceasta, au existat și alte cazuri, mai puțin dramatice, în care depanarea ne-a condus la codul deja marcat /analiza. Toate acestea au fost greșeli reale.

În cele din urmă, am primit tot codul folosit pentru a compila într-un fișier executabil 360 fără un singur avertisment când /analyze a fost activat și am setat acest mod de compilare ca implicit pentru versiunile 360. După aceea, fiecare programator care lucra pe aceeași platformă și-a verificat codul pentru erori de fiecare dată când a fost compilat, astfel încât să poată remedia imediat erorile pe măsură ce erau introduse în program, în loc să fiu nevoit să mă ocup de ele mai târziu. Desigur, acest lucru a încetinit puțin procesul de compilare, dar /analyze este de departe cel mai rapid instrument pe care l-am folosit vreodată și, credeți-mă, merită.

Odată ce am dezactivat accidental analiza statică într-un proiect. Au trecut câteva luni, iar când am observat acest lucru și l-am pornit din nou, instrumentul a lansat o grămadă de noi avertismente de eroare care au fost adăugate codului în acel timp. De asemenea, programatorii doar pentru PC sau PS3 contribuie cu coduri greșite la depozit și rămân în întuneric până când primesc un e-mail care raportează o „build 360 eșuată”. Aceste exemple demonstrează clar că dezvoltatorii fac anumite tipuri de greșeli din nou și din nou în cursul activităților lor zilnice și /analiza ne-a protejat în mod fiabil de majoritatea dintre ele.

PVS-Studio

Deoarece am putut folosi /analiza numai pe cod 360, o mare parte din baza noastră de cod a fost încă lăsată neacoperită de analiza statică - aceasta includea codul pentru platformele PC și PS3, precum și toate programele care rulează numai pe PC.

Următorul instrument cu care m-am familiarizat a fost PVS-Studio. Se integrează cu ușurință în Visual Studio și oferă un mod demonstrativ convenabil (încercați-l singur!). În comparație cu /analyze, PVS-Studio este teribil de lent, dar a reușit să prindă o serie de noi erori critice, chiar și în codul care fusese deja complet curățat din punctul de vedere al /analyze. Pe lângă erorile evidente, PVS-Studio prinde multe alte defecte, care sunt clișee de programare eronate, chiar dacă par cod normal la prima vedere. Din această cauză, un anumit procent de fals pozitive este aproape inevitabil, dar, la naiba, am găsit astfel de modele în codul nostru și le-am corectat.

Pe site-ul PVS-Studio puteți găsi un număr mare de articole minunate despre instrument, iar multe dintre ele conțin exemple din proiecte reale open-source, ilustrând în mod specific tipurile de erori discutate în articol. M-am gândit să inserez aici câteva mesaje de diagnostic ilustrative produse de PVS-Studio, dar pe site au apărut deja exemple mult mai interesante. Așa că vizitați pagina și vedeți singuri. Și da - când citești aceste exemple, nu rânji și spune că nu ai scrie niciodată așa.

PC-Lint

În cele din urmă, am revenit la opțiunea de a folosi PC-Lint împreună cu Visual Lint pentru integrarea în mediul de dezvoltare. În conformitate cu tradiția legendară a lumii Unix, instrumentul poate fi configurat pentru a îndeplini aproape orice sarcină, dar interfața sa nu este foarte ușor de utilizat și nu o puteți pur și simplu „prelua și rula”. Am achiziționat un set de cinci licențe, dar s-a dovedit a fi atât de laborios încât, din câte știu, toți ceilalți dezvoltatori l-au abandonat în cele din urmă. Flexibilitatea are beneficiile ei - de exemplu, am putut să-l configurez pentru a testa tot codul nostru pentru platforma PS3, deși acest lucru a durat mult timp și efort.

Și din nou, în codul care era deja curat din punct de vedere al /analyze și al PVS-Studio, s-au găsit noi erori importante. Am încercat sincer să-l curăț, astfel încât scamele să nu înjure, dar nu am reușit. Am reparat tot codul de sistem, dar am renunțat când am văzut câte avertismente dădea pentru codul jocului. Am sortat erorile în clase și m-am ocupat de cele mai critice dintre ele, ignorând multe altele care erau mai mult legate de defecte stilistice sau potențiale probleme.

Cred că încercarea de a remedia o cantitate imensă de cod cât mai mult posibil din punct de vedere al PC-Lint este sortită eșecului. Am scris o anumită cantitate de cod de la zero în acele locuri în care am încercat cu ascultare să scap de orice comentariu enervant „Lint”, dar pentru majoritatea programatorilor experimentați C/C++ această abordare a lucrului la erori este prea mult. Încă trebuie să schimb cu setările PC-Lint pentru a găsi cel mai bun set de avertismente pentru a profita la maximum de instrument.

concluzii

Am învățat multe trecând prin toate acestea. Mi-e teamă că unele dintre concluziile mele vor fi dificile pentru oamenii care nu au trebuit să trimită personal sute de rapoarte de erori într-un interval de timp scurt și să se simtă rău de fiecare dată când încep să le editeze, iar reacția standard la cuvintele mele va fi fii „bine, avem atunci totul este bine” sau „nu totul este atât de rău”.

Primul pas pe această cale este să recunoști cu sinceritate față de tine că codul tău este plin de erori. Pentru majoritatea programatorilor, aceasta este o pastilă amară de înghițit, dar fără a o înghiți, veți percepe inevitabil orice propunere de schimbare și îmbunătățire a codului cu iritare, sau chiar ostilitate nedisimulata. Trebuie să vă vrei supun codul dvs. criticilor.

Automatizarea este necesară. Este greu să nu simți un sentiment de schadenfreude când vezi rapoarte de defecțiuni îngrozitoare în sistemele automate, dar pentru fiecare defecțiune de automatizare există o legiune de erori umane. Apelurile pentru a „scrie un cod mai bun”, solicitările bine intenționate pentru mai multe recenzii de cod, programarea perechilor și așa mai departe pur și simplu nu funcționează, mai ales când sunt zeci de oameni implicați în proiect și munca trebuie făcută în grabă. . Valoarea enormă a analizei statice constă în abilitate de fiecare dată când începi găsiți cel puțin porțiuni mici de erori accesibile acestei tehnici.

Am observat că la fiecare actualizare, PVS-Studio a găsit din ce în ce mai multe erori în codul nostru datorită noilor diagnostice. Din aceasta putem concluziona că atunci când baza de cod ajunge la o anumită dimensiune, pare să introducă toate erorile care sunt acceptabile din punct de vedere al sintaxei. În proiectele mari, calitatea codului este supusă acelorași legi statistice ca și proprietățile fizice ale materiei - defectele sunt omniprezente și puteți încerca doar să minimizați impactul lor asupra utilizatorilor.

Instrumentele de analiză statică sunt forțate să funcționeze cu o mână legată la spate: trebuie să facă inferențe bazate pe limbaje de analiză care nu oferă neapărat informații pentru astfel de inferențe și, în general, fac presupuneri foarte prudente. Prin urmare, ar trebui să vă ajutați analizatorul cât mai mult posibil - favorizați indexarea față de aritmetica pointerului, păstrați graficul de apel într-un singur fișier sursă, utilizați adnotări explicite etc. Orice lucru care nu pare evident pentru un analizor static va deruta aproape sigur colegii dvs. programatori. Aversiunea caracteristică „hackerului” față de limbaje cu tastare statică strictă („limbaje de sclavie și disciplină”) se dovedește a fi miop: nevoile proiectelor mari, de lungă durată, în dezvoltarea cărora sunt echipe mari de programatori. implicate, sunt radical diferite de sarcinile mici și rapide efectuate pentru sine.

Pointerii nuli sunt cea mai presantă problemă în limbajul C/C++, cel puțin aici. Posibilitatea utilizării duble a unei singure valori atât ca flag, cât și ca adresă duce la un număr incredibil de erori critice. Prin urmare, ori de câte ori este posibil, C++ ar trebui să favorizeze referințele față de pointeri. Deși referința nu este „cu adevărat” nimic mai mult decât un indicator, este legată de un angajament implicit că nu poate fi nulă. Efectuați verificări nule pe pointeri atunci când acestea sunt transformate în referințe - acest lucru vă va permite să uitați de această problemă mai târziu. Există o mulțime de modele de programare profund înrădăcinate în industria jocurilor care sunt potențial periculoase, dar nu cunosc o modalitate de a trece complet și fără durere de la verificări nule la referințe.

A doua cea mai importantă problemă din baza noastră de cod au fost erorile cu funcțiile printf. A fost și mai agravată de faptul că trecerea idStr în loc de idStr::c_str() a dus la prăbușirea programului aproape de fiecare dată. Cu toate acestea, când am început să folosim adnotări /analiza pe funcțiile variadice pentru a ne asigura că verificările de tip au fost efectuate corect, problema a fost rezolvată o dată pentru totdeauna. În avertismentele utile ale analizorului, am întâlnit zeci de astfel de defecte care ar putea duce la un accident dacă s-ar întâmpla o condiție eronată să declanșeze ramura de cod corespunzătoare - aceasta, apropo, arată și cât de mic a fost acoperit procentul codului nostru. prin teste.

Multe dintre erorile grave raportate de analizor s-au datorat modificărilor aduse codului mult timp după ce a fost scris. Un exemplu incredibil de comun este în cazul în care codul ideal, care a verificat anterior pointerii pentru nul înainte de a efectua o operație, a fost ulterior modificat în așa fel încât pointerii au început brusc să fie utilizați fără verificare. Dacă ne uităm la această problemă izolat, ne-am putea plânge de complexitatea ciclomatică mare a codului, dar dacă ne uităm în istoria proiectului, se dovedește că motivul este mai probabil că autorul codului nu a reușit să reușească clar. comunicați premisele programatorului care a fost ulterior responsabil de refactorizare.

O persoană, prin definiție, nu este capabilă să mențină atenția asupra tuturor deodată, așa că, în primul rând, concentrează-te pe codul pe care îl vei livra clienților și acordă mai puțină atenție codului pentru nevoile interne. Migrați activ codul din baza de date de vânzări către proiectele interne. A fost publicat recent un articol care spunea că toate valorile de calitate a codului, în toată diversitatea lor, se corelează aproape la fel de perfect cu dimensiunea codului ca și rata de eroare, ceea ce face posibilă prezicerea numărului de erori cu o precizie ridicată doar pe baza dimensiunii codului. Așadar, reduceți partea de cod care este critică din punct de vedere al calității.

Dacă nu ați fost complet îngrozit de toate provocările suplimentare pe care le aduce programarea paralelă, se pare că pur și simplu nu v-ați gândit suficient la asta.

Este imposibil să efectuăm teste de referință de încredere în dezvoltarea de software, dar succesul nostru în utilizarea analizei codului a fost atât de clar încât pot spune pur și simplu: A nu folosi analiza codului este iresponsabil! Jurnalele automate de blocare ale consolei oferă date obiective care arată clar că Rage, deși este un pionier în multe privințe, s-a dovedit a fi mult mai stabil și mai sănătos decât majoritatea jocurilor de ultimă generație. Lansarea Rage pe PC a eșuat, din păcate, - sunt dispus să pariez că AMD nu utilizează analiza statică atunci când își dezvoltă driverele grafice.

Iată o rețetă gata făcută: dacă versiunea dvs. de Visual Studio are /analiza încorporat, activați-l și încercați-l așa. Dacă mi s-ar cere să aleg unul dintre multele instrumente, aș alege această soluție de la Microsoft. Îi sfătuiesc pe toți ceilalți care lucrează în Visual Studio să încerce cel puțin PVS-Studio în modul demo. Dacă dezvoltați software comercial, achiziționarea de instrumente de analiză statică va fi una dintre cele mai bune investiții pe care le puteți face.

Și în sfârșit, un comentariu de pe Twitter.

Termenul este de obicei aplicat analizelor efectuate de software special, în timp ce analiza manuală este numită înţelegere sau intelegere programe.

În funcție de instrumentul utilizat, profunzimea analizei poate varia de la identificarea comportamentului declarațiilor individuale până la o analiză care include tot codul sursă disponibil. Modalitățile de utilizare a informațiilor obținute în timpul analizei sunt, de asemenea, diferite - de la identificarea locurilor care pot conține erori, până la metode formale care fac posibilă demonstrarea matematică a oricăror proprietăți ale programului (de exemplu, conformitatea comportamentului cu specificația).

Unii oameni cred metrici softwareȘi Inginerie inversă forme de analiză statică.

Recent, analiza statică a fost folosită din ce în ce mai mult în verificare proprietățile software-ului utilizat în sisteme informatice de înaltă fiabilitate.

Majoritatea compilatoarelor (de exemplu, GNU C Compiler) afișează „avertismente” ( Engleză Avertizări) - mesaje că codul, deși corect din punct de vedere sintactic, conține cel mai probabil o eroare. De exemplu:

Int x; int y = x+ 2 ; // Variabila x nu este inițializată!

Aceasta este cea mai simplă analiză statică. Compilatorul are multe alte caracteristici importante - în primul rând, viteza și calitatea codului mașină, astfel încât compilatorii verifică codul numai pentru erori evidente. Analizoarele statice sunt proiectate pentru o analiză mai detaliată a codului.

Tipuri de erori detectate de analizoarele statice

• Comportament nedefinit- variabile neinițializate, acces la pointeri NULL. Compilatorii semnalează și cele mai simple cazuri.
• Încălcarea diagramei de utilizare a bibliotecii. De exemplu, fiecare fopen are nevoie de un fclose . Și dacă variabila fișier este pierdută înainte ca fișierul să fie închis, analizorul poate raporta o eroare.
• Scenarii comune care duc la un comportament nedocumentat. Biblioteca C Standard este cunoscută pentru numeroasele sale soluții tehnice slabe. Unele caracteristici de ex. devine, sunt fundamental nesigure. sprintfȘi strcpyîn siguranță numai în anumite condiții.
• Buffer overflow- când un program de calculator scrie date dincolo de buffer-ul alocat în memorie.

Void do Something(const char * x) ( char s[ 40 ] ; sprintf (s, "[%s]" , x) ; // sprintf către bufferul local, posibil depășire .... }

• Scenarii tipice care interferează multiplatformă.

Obiect * p = getObject() ; int pNum = reinterpret_cast< int >(p); // pe x86-32 adevărat, pe x64 o parte a indicatorului se va pierde; nevoie de size_t

• Erori în cod dublu. Multe programe execută același lucru de mai multe ori cu argumente diferite. De obicei, fragmentele repetate nu sunt scrise de la zero, ci reproduceși reparați-o.

Dest.x = src.x + dx; dest.y = src.y + dx; // Eroare, trebuie!

Std::wstring s; printf ("s este %s", s);

• Un parametru neschimbat transmis unei funcții este un semn al cerințelor modificate pentru program. Pe vremuri parametrul era activat, dar acum nu mai este necesar. În acest caz, programatorul poate scăpa complet de acest parametru - și de logica asociată acestuia.

Void do Something (int n, bool flag) // steag este întotdeauna adevărat( dacă (steagul) ( // ceva logică) altfel ( // codul este acolo, dar nu este folosit) ) face Something(n, true ) ; ... face Something(10, true); ... face Something(x.size(), true);

Std::string s; ...s.gol(); // codul nu face nimic; probabil te-ai referit la clar()?

Metode formale

Instrumente de analiză statică

• Acoperire
• lint și lock_lint sunt incluse în Sun Studio
• T-SQL Analyzer este un instrument care poate vizualiza modulele programului din bazele de date care rulează Microsoft SQL Server 2005 sau 2008 și detectează potențiale probleme din cauza calității proaste a codului.
• AK-VS

Vezi si

• Semantica formală a PL
• Analiza software
• Degradarea treptată
• SPARK - japoneză

Note

Legături

Fundația Wikimedia. 2010.

Vedeți ce este „Analiza codului static” în alte dicționare:

- (Engleză: Dynamic program analysis) analiza software efectuată prin executarea de programe pe un procesor real sau virtual (analiza efectuată fără programe în rulare se numește analiză de cod statică). Utilități... ...Wikipedia

Analiza fluxului de control este o analiză statică a codului pentru a determina ordinea în care este executat un program. Ordinea de execuție este exprimată ca un grafic al fluxului de control. Pentru multe limbi, graficul fluxului de control este clar vizibil în codul sursă... ... Wikipedia

Acest termen are alte semnificații, vezi BLAST (sensuri). Tip BLAST Instrumente de analiză statică Dezvoltator Dirk Beyer, Thomas Henzinger, Ranjit Jhala, Rupak Majumdar, Berkeley Sistem de operare Linux, Microsoft Windows... ... Wikipedia

Următoarele tabele includ pachete software care sunt instrumente de dezvoltare integrate. Compilatoarele și depanatoarele individuale nu sunt menționate. Poate că există informații mai recente în secțiunea în limba engleză. Cuprins 1 ActionScript 2 Ada 3 ... Wikipedia

Depanarea este etapa de dezvoltare a programelor de calculator în care erorile sunt detectate, localizate și eliminate. Pentru a înțelege unde a apărut eroarea, trebuie să: aflați valorile curente ale variabilelor; afla ce cale a fost folosita... ... Wikipedia

Tip Analizor de cod static Dezvoltator BiPro laborator Scris în C++ Sistem de operare Multi-platformă Limbi de interfață Engleză... Wikipedia

Oamenii fac greșeli când scriu cod în C și C++. Multe dintre aceste erori sunt găsite datorită -Wall , aserțiunilor, testelor, revizuirilor meticuloase de cod, avertismentelor din IDE, construirea proiectului cu compilatoare diferite pentru diferite sisteme de operare care rulează pe hardware diferit și așa mai departe. Dar chiar și cu toate aceste măsuri, erorile rămân adesea nedetectate. Analiza codului static poate îmbunătăți puțin situația. În această notă ne vom familiariza cu câteva instrumente pentru efectuarea acestei analize foarte statice.

CppCheck

CppCheck este un analizor static multiplatform gratuit, open source (GPLv3). Este disponibil în pachete cu multe sisteme *nix din cutie. CppCheck se poate integra și cu multe IDE-uri. La momentul scrierii acestui articol, CppCheck este un proiect viu, în curs de dezvoltare.

Exemplu de utilizare:

cppcheck ./src/

Exemplu de ieșire:

: (eroare) Greșeală comună de realloc: „numarr” null, dar nu
eliberat la eşec

: (eroare) Utilizarea periculoasă a „n” (strncpy nu întotdeauna
nul-termină)

CppCheck este bun pentru că funcționează destul de repede. Nu există niciun motiv să nu adăugați rularea acestuia la sistemul de integrare continuă pentru a corecta toate, toate, toate avertismentele pe care le afișează. Chiar dacă multe dintre ele se dovedesc a fi false pozitive în practică.

Analizor static Clang

Un alt analizor static gratuit, open-source, multiplatformă. Face parte din așa-numita stivă LLVM. Spre deosebire de CppCheck, funcționează semnificativ mai lent, dar găsește și erori mult mai grave.

Exemplu de creare a unui raport pentru PostgreSQL:

CC =/ usr/ local/ bin/ clang38 CFLAGS ="-O0 -g" \
./ configure --enable-cassert --enable-debug
face curat
mkdir../report-201604/
/ usr/ local/ bin/ scan-build38 -o ../ report-201604 / gmake -j2

Un exemplu de generare a unui raport pentru nucleul FreeBSD:

# folosind propriul dvs. MAKEOBJDIR vă permite să construiți nucleul fără root
mkdir/tmp/freebsd-obj
# ansamblul în sine
COMPILER_TYPE =clang / usr/ local/ bin/ scan-build38 -o ../ report-201604 / \
make buildkernel KERNCONF =MAKEOBJDIRPREFIX GENERIC =/ tmp/ freebsd-obj

Ideea, după cum ați putea ghici, este să faceți o curățare și apoi să rulați build-ul sub scan-build.

Rezultatul este un raport HTML foarte frumos cu explicații detaliate, capacitatea de a filtra erorile după tip și așa mai departe. Asigurați-vă că vă uitați pe site pentru a vedea cum arată.

În acest context, nu pot să nu remarc că în lumea Clang/LLVM există și instrumente dinamic analiză, așa-numiții „dezinfectanți”. Sunt multe dintre ele, găsesc erori foarte interesante și funcționează mai repede decât Valgrind (deși numai pe Linux). Din păcate, o discuție despre dezinfectanți depășește scopul acestei note, așa că citiți-le singur.

PVS-Studio

Un analizor static închis, distribuit pentru bani. PVS-Studio funcționează numai sub Windows și numai cu Visual Studio. Există numeroase informații despre existența unei versiuni Linux, dar aceasta nu este disponibilă pe site-ul oficial. Din cate am inteles, pretul licentei se discuta individual cu fiecare client. Probă disponibilă.

Am testat PVS-Studio 6.02 pe Windows 7 SP1 care rulează sub KVM cu Visual Studio 2013 Express Edition instalat. În timpul instalării PVS-Studio, a fost descărcat și .NET Framework 4.6. Arata cam asa. Deschideți proiectul (am testat pe PostgreSQL) în Visual Studio, în PVS-Studio faceți clic pe „acum voi începe să construiesc proiectul”, apoi în Visual Studio faceți clic pe Build, când construirea este completă în PVS-Studio faceți clic pe „I’ am terminat” și vezi raportul.

PVS-Studio găsește într-adevăr erori foarte interesante pe care Clang Static Analyzer nu le vede (de exemplu). Mi-a plăcut foarte mult și interfața, care vă permite să sortați și să filtrați erorile după tipul lor, severitate, fișierul în care au fost găsite etc.

Pe de o parte, este trist că, pentru a utiliza PVS-Studio, proiectul trebuie să se poată compila sub Windows. Pe de altă parte, utilizarea CMake într-un proiect și construirea și testarea acestuia sub diferite sisteme de operare, inclusiv Windows, este o idee foarte bună în orice caz. Deci, poate că acesta nu este un dezavantaj atât de mare. În plus, la următoarele link-uri puteți găsi câteva indicii despre cum au reușit oamenii să ruleze PVS-Studio pe proiecte care nu sunt construite pentru Windows: unu, doi, trei, patru.

Plus: Am încercat versiunea beta a PVS-Studio pentru Linux. S-a dovedit a fi foarte ușor de folosit. Creăm pvs.conf cu aproximativ următorul conținut:

lic-file=/home/afiskon/PVS-Studio.lic
output-file=/home/afiskon/postgresql/pvs-output.log

Apoi spunem:

face curat
./ configura...
pvs-studio-analyzer trace -- make
# va fi creat un fișier strace_out mare (pentru mine ~40 MB).
pvs-studio-analyzer analizează --cfg ./ pvs.conf
plog-converter -t tasklist -o result.task pvs-output.log

Plus: PVS-Studio pentru Linux a părăsit versiunea beta și este acum disponibil pentru toată lumea.

Scanare de acoperire

Coverity este considerat unul dintre cele mai sofisticate (și, prin urmare, costisitoare) analizoare statice. Din păcate, este imposibil să descărcați chiar și versiunea sa de probă pe site-ul oficial. Puteți completa formularul și dacă sunteți o persoană IBM, puteți fi contactat. La Foarte Dorința puternică a Coverity pentru o versiune preistorică poate fi găsită prin canale neoficiale. Este disponibil pentru Windows și Linux și funcționează aproximativ pe același principiu ca PVS-Studio. Dar fără un număr de serie sau un medicament, Coverity nu vă va arăta rapoarte. Și pentru a găsi un număr de serie sau un medicament, trebuie să ai nu doar o dorință foarte puternică, ci o foarte, foarte... Foarte puternic.

Din fericire, Coverity are o versiune SaaS - Coverity Scan. Nu numai că Coverity Scan este accesibilă simplilor muritori, ci este și complet gratuit. Nu există nicio conexiune la o anumită platformă. Cu toate acestea, numai proiectele deschise pot fi analizate folosind Coverity Scan.

Iată cum funcționează. Vă înregistrați proiectul prin interfața web (sau vă alăturați unuia existent, dar acesta este un caz mai puțin interesant). Pentru a vizualiza rapoarte, trebuie să treceți prin moderare, care durează 1-2 zile lucrătoare.

Rapoartele sunt construite astfel. În primul rând, vă construiți proiectul local folosind un utilitar special numit Coverity Build Tool. Acest utilitar este similar cu scanarea-build de la Clang Static Analyzer și este disponibil pentru toate platformele imaginabile, inclusiv pentru toate cele exotice, cum ar fi FreeBSD sau chiar NetBSD.

Instalarea instrumentului Coverity Build:

tar -xvzf cov-analysis-linux64-7.7.0.4.tar.gz
export PATH =/ home/ eax/ temp/ cov-analysis-linux64-7.7.0.4/ bin:$PATH

Să pregătim un proiect de testare (am folosit codul din postare Să continuăm să învățăm OpenGL: text simplu):

git clone git @ github.com:afiskon/ c-opengl-text.git
cd c-opengl-text
git submodule init
actualizare submodulului git
mkdir build
CD build
face..

Apoi asamblam proiectul sub cov-build:

cov-build --dir cov-int make -j2 demo emdconv

Important! Nu schimbați numele directorului cov-int.

Arhivați directorul cov-int:

tar -cvzf c-opengl-text.tgz cov-int

Încărcați arhiva prin intermediul formularului Încărcați un proiect. Există, de asemenea, instrucțiuni pe site-ul web Coverity Scan pentru automatizarea acestui pas folosind curl. Așteptăm puțin și putem vedea rezultatele analizei. Vă rugăm să rețineți că pentru a trece de moderare, trebuie să trimiteți cel puțin o versiune pentru analiză.

Coverity Scan caută foarte bine erorile. Cu siguranță mai bun decât Clang Static Analyzer. În același timp, există false pozitive, dar sunt mult mai mici. În mod convenabil, interfața web are ceva asemănător unui instrument de urmărire a erorilor încorporat care vă permite să atribuiți o severitate erorilor, cine este responsabil pentru remedierea lor și lucruri similare. Puteți vedea care erori sunt noi și care erau deja în versiunile anterioare. Falsele pozitive pot fi semnalate ca atare și ascunse.

Vă rugăm să rețineți că nu trebuie să fiți proprietarul pentru a analiza un proiect în Coverity Scan. Personal am avut destul succes în analiza codului PostgreSQL fără a mă alătura unui proiect existent. De asemenea, se pare că dacă doriți cu adevărat (de exemplu, folosind submodule Git), puteți introduce un cod sursă puțin și nu foarte deschis pentru revizuire.

Concluzie

Iată mai multe analizoare statice care nu au fost incluse în recenzie:

Fiecare dintre analizatorii analizați găsește erori pe care alții nu le găsesc. Prin urmare, în mod ideal este mai bine să le folosiți pe toate simultan. Făcând acest lucru direct tot timpul, cel mai probabil nu va funcționa obiectiv. Dar să faci cel puțin o rulare înainte de fiecare lansare cu siguranță nu va fi o idee rea. În același timp, Clang Static Analyzer pare a fi cel mai versatil și, în același timp, destul de puternic. Dacă sunteți interesat de un analizor care este obligatoriu pentru orice proiect, utilizați-l pe acesta. Dar totuși, aș recomanda utilizarea suplimentară a cel puțin PVS-Studio sau Coverity Scan.

Ce analizoare statice ați încercat și/sau folosit în mod regulat și care sunt impresiile dvs. despre ele?