È saggio usare Clang per l'analisi del codice personale in un progetto che costruisce con gcc?

Naviga le tue risposte
8

Ho iniziato a lavorare su diversi progetti C che stanno costruendo usando gcc . Credo che questa scelta sia stata fatta per diversi motivi:

  • È stato necessario eseguire il cross-compile per il braccio molto presto (credo).
  • Le prestazioni sono la prima e la più importante.
  • gcc era ed è ancora la prima scelta facile.

Non ho motivo di contestare questa scelta e non sono in grado di farlo comunque.

Il codice base di ogni singolo progetto è relativamente piccolo. Ogni progetto si costruisce con un Makefile relativamente pulito (attualmente in fase di aggiornamento), gcc -Wall -Wextra non si lamenta affatto e viene eseguito un test minimo. Non c'è l'analisi statica automatica o la formattazione del codice in corso e il codice è sintatticamente non coerente, anche se è molto leggibile e si sente pensato.

Non voglio riformattare tutte le righe di codice contemporaneamente, ho intenzione di fare come descritto da qualche parte intorno a questa risposta (soprattutto dal momento che il contesto non è poi così male): refactoring e principalmente riformattazione il più possibile quando si ha a che fare con qualsiasi argomento, ma affrontare gli argomenti senza intenzioni di stile del codice in mente. Sfortunatamente, non sono in grado di imporre uno stile di codice o ulteriori controlli sui commit, ma sento che tra i miei colleghi c'è il senso che dovresti rispettare la convenzione di codice esistente quando modifichi un file (anche se sono consapevole dello stato attuale del codice non è accaduto magicamente), e il desiderio di scrivere un buon codice.

Questa è la mia prima programmazione in C con un tale stato d'animo, e sono molto attratto dai vari strumenti di analisi e formattazione del codice che clang fornisce.

L'essenza della mia domanda è quindi: potrebbe portare a problemi a seguire clang suggerimenti e usare clang strumenti di formattazione e analisi mentre si costruisce con gcc ? Ad esempio, alcuni avvertimenti potrebbero provenire da una rappresentazione interna che gcc non utilizza, o dal codice byte clang che avrebbe intenzione di generare che gcc non lo farà.

Esiste un buon modo per passare automaticamente i parametri di compilazione gcc (principalmente l'architettura di destinazione e il livello di ottimizzazione) a clang in modo che gli avvertimenti di avviso abbiano senso?

Aggiungerò che ho familiarità con gcc e la sua segnalazione degli errori. Sono interessato a ricevere più (rilevanti) avvertimenti ed errori, non solo avvertimenti più chiari e più comprensibili. Quindi, se non posso fidarmi di ulteriori suggerimenti che clang può produrre in base alla sua rappresentazione interna, perché con la creazione di gcc alla fine della giornata, quindi non sono molto interessato a farlo.

Ho incluso un sacco di contesto, quindi sentitevi liberi di fare qualsiasi osservazione o di rispondere a qualsiasi domanda sottostante che non potevo evidenziare.

    
posta nathdwek 31.08.2016 - 12:50
fonte

2 risposte

9

For example, some warnings could come from an internal representation gcc does not use, or from bytecode clang would intend to generate that gcc won't.

Estremamente improbabile. Clang ti avvisa del codice tuo , non di una rappresentazione interna che usa. Tutti gli avvertimenti dovrebbero derivare da qualcosa di sospetto che stai facendo nel tuo codice, non da eventuali dettagli di implementazione di clang.

Dove potresti avere problemi è se uno qualsiasi dei codici che stai usando utilizza C ++ non standard. GCC supporta molte estensioni a C ++ che non saranno accettate da altri compilatori. Se usi qualcuno di questi, clang potrebbe semplicemente rifiutarsi di compilare il tuo codice. GCC deve supportare la compilazione di un sacco di vecchio codice e (a quanto ho capito) è più indulgente su alcuni punti rispetto a Clang.

    
risposta data 31.08.2016 - 17:34
fonte
2

Sto usando entrambi al lavoro, gcc e clang. Avrai sempre più avvertimenti con entrambi i compilatori, naturalmente, e questo è grandioso. D'altra parte gli avvertimenti possono contraddirsi l'un l'altro.

Il caso più fastidioso che ho trovato è quando clang rileva una regola default in switch e dice che tutti i valori sono già coperti e gcc insiste per avere default caso (documentato here ). Ma vedrai questa contraddizione solo quando imposti avvisi molto rigidi su entrambi i compilatori.

Soggettivamente, direi che clang ha avvertimenti più rigidi e puoi persino ottenerne di più se usi -Weverything o anche clang analyzer (analizzatore di codice statico). Ma ho anche avvertito che gcc ha scoperto ed era anche importante.

La maggior parte degli switch del compilatore ha esattamente lo stesso nome. I nomi degli interruttori di avviso sono diversi. Ciò può essere fastidioso se si decide di utilizzare le opzioni -Wno-* per disabilitare gli avvisi. Non sarai in grado di evitare la compilazione condizionale in make / cmake, per quanto posso vedere, ma non è difficile risolverlo.

Eviterei di formattare il codice con strumenti automatici. È fastidioso perché inquina l'uscita della colpa. E poi le fusioni di lunga data possono diventare molto difficili.

    
risposta data 31.08.2016 - 20:23
fonte

Leggi altre domande sui tag

Metodi astratti vs variabili di istanza per oggetti riutilizzabili Cosa fare quando il tuo collega di lavoro non capisce il design che cerca di essere mantenuto [chiuso]