Come faccio a dire gcov di ignorare le linee non-hittable di codice C ++?

Question

sto usando gcov alla copertura misura nel mio codice C ++. Mi piacerebbe arrivare a una copertura del 100%, ma sto ostacolata dal fatto che ci sono alcune linee di codice che sono teoricamente non-hittable (metodi che sono necessari per essere attuato, ma che non sono mai chiamati, rami di default di dichiarazioni switch, eccetera.). Ognuno di questi rami contiene una dichiarazione assert( false );, ma gcov ancora un segnale come non-hit.

Mi piacerebbe essere in grado di dire gcov di ignorare questi rami. Esiste un modo per dare gcov che le informazioni -? Annotando il codice sorgente, o con qualsiasi altro meccanismo

Answer 1

Si prega di utilizzare lcov. Nasconde la complessità di gcov, produce un output bello, permette l'output dettagliato per test, caratteristiche di facile file di filtraggio e - ta-TAA - marcatori di linea per le linee già recensiti:

Da geninfo (1):

  

I seguenti marcatori sono riconosciuti da geninfo:

     

  
• LCOV_EXCL_LINE   
    
  • verranno esclusi Linee che contengono questo marcatore.
    
  
• LCOV_EXCL_START   
    
  • segna l'inizio di una sezione esclusi. L'attuale linea è parte di questa sezione.
    
  
• LCOV_EXCL_STOP   
    
  • Segna la fine di una sezione esclusi. L'attuale linea non fa parte di questa sezione.
    
  

Answer 2

Uno strumento chiamato gcovr può essere utilizzato per riassumere l'output di gcov, e (from almeno la versione 3.4 ) supportare gli stessi marcatori di esclusione lcov.

questa risposta :

  

I seguenti marcatori sono riconosciuti da geninfo:

     

  
• LCOV_EXCL_LINE      
    
  • verranno esclusi Linee che contengono questo marcatore.
    
  
• LCOV_EXCL_START      
    
  • segna l'inizio di una sezione esclusi. L'attuale linea è parte di questa sezione.
    
  
• LCOV_EXCL_STOP      
    
  • Segna la fine di una sezione esclusi. L'attuale linea non fa parte di questa sezione.
    
  

Si può anche sostituire 'LCOV' sopra con 'GCOV' o 'GCOVR'. Hanno tutti i lavori.

Answer 3

Puoi presentarti unit test delle funzioni competenti, che esistono solo per gcov Shut Up attaccando direttamente i percorsi di codice in teoria-unhittable? Dato che sono test di unità, si potrebbe forse ignorare il "impossibile" delle situazioni. Potevano chiamare le funzioni che non vengono mai chiamati, passare valori enum non validi per la cattura di rami di default, ecc.

Allora o eseguire questi test solo sulla versione del codice compilato con NDEBUG, oppure eseguirli in un cablaggio che le prove che l'asserzione viene attivato -. Qualunque sia il vostro supporti framework di test

Lo trovo un po 'strano anche se per le specifiche di dire che il codice deve essere lì, piuttosto che la specifica contenente requisiti funzionali sul codice. In particolare, ciò significa che i test non stanno testando tali requisiti, che è come la ragione una buona come un altro per mantenere i requisiti funzionali. Personalmente vorrei modificare le specifiche di dire, "se chiamato con un valore di enumerazione non valido, la funzione mancherà un assert. I chiamanti non devono chiamare la funzione con un valore di enumerazione non valida in modalità di rilascio". O qualcosa del genere.

Probabilmente quello che attualmente dice, è sulla falsariga di "tutte le istruzioni switch devono avere un caso di default". Ma che mezzi di codifica standard interferiscono con il comportamento osservabile (almeno, osservabile sotto gcov) introducendo codice morto. standard di codifica non dovrebbero farlo, per cui la specifica funzionale deve tener conto delle norme di codifica, se possibile.

In mancanza di questo, si potrebbe forse avvolgere il codice unhittable in #if !GCOV_BUILD, e fare una costruzione separata a beneficio di gcov. Questa build fallirà alcuni requisiti, ma alla condizione che la tua analisi del codice essere corretto, ti dà la fiducia che si desidera che il test della suite di test tutto il resto.

Modifica: si dice che si sta utilizzando un generatore di codice dubbia, ma si sta anche chiedendo una soluzione annotando il codice sorgente. Se stai cambiando la fonte, si può solo rimuovere il codice morti in molti casi? Non fonte che cambiare generato è l'ideale, ma ha bisogno di deve ...

Answer 4

Non credo che questo sia possibile. Gcov dipende da gcc per generare codice aggiuntivo per produrre l'output di copertura. Gcov sé solo analizza i dati. Ciò significa che gcov non può analizzare il codice meglio di gcc (e presumo si utilizza -Wall e hanno rimosso il codice riportato come irraggiungibile).

Ricordate che le funzioni relocatable può essere chiamato da qualsiasi luogo, potenzialmente anche DLL esterne o eseguibili quindi non c'è alcun modo in cui il compilatore può sapere quali funzioni relocatable non saranno chiamati o che cosa ingresso queste funzioni possono avere.

Probabilmente avrà bisogno di utilizzare alcuni tool di analisi statica facy per ottenere le informazioni che si desidera.