Ho trovato un "bug" nel mio codice (l'unico ;-) che fa scattare da quella, e che non viene rilevato da -Wall
. L'ho cucinato al seguente
struct elem {
struct elem *prev;
struct elem *next;
};
#define ELEM_INITIALIZER(NAME) { .prev = &(NAME), .next = &(NAME), }
struct head {
struct elem header;
};
#define HEAD_INITIALIZER(NAME) { .header = ELEM_INITIALIZER(NAME.header) }
int main(int argc, char ** argv) {
struct head myhead = HEAD_INITIALIZER(myhead);
}
Questa è un'implementazione relativamente semplice di un elenco collegato, ma qui non è importante. La variabile myhead
non è utilizzata in un'applicazione di senso comune del termine, ma per il compilatore viene utilizzata poiché all'interno dell'inizializzatore viene utilizzato l'indirizzo di un campo.
clang
analisi correttamente questa come
/tmp 11:58 <722>% clang --analyze test-clang.c
test-clang.c:25:15: warning: Value stored to 'myhead' during its initialization is never read
struct head myhead = HEAD_INITIALIZER(myhead);
^ ~~~~~~~~~~~~~~~~~~~~~~~~
1 diagnostic generated.
Edit: ho trovato un altro che rileva anche la proliferazione memoria pila
char const* myBuggyFunction(void) {
return (char[len + 1]){ 0 };
}
Questo non viene rilevato da gcc
, open64
o clang
con -Wall
, ma da clang
con --analyze
.
fonte
2010-08-15 10:06:40
Fa il lavoro, grazie :) Devo dire, ho trovato le fughe di memoria sanguinarie più ovvie e creative che ho potuto inventare, e le ho lasciate passare tutte. Chiaramente ne sa abbastanza per sapere che lo stavo testando. – detly
@detly: è stato divertente, appreso clangare da esso :) per la mia curiosità quali sono le perdite in un contesto di analisi statica? –
Beh, non sono sicuro al 100%, ma avevo l'impressione che molti strumenti di analisi statica, incluso clang, possano rilevare potenziali problemi di memoria in fase di esecuzione (come ad esempio 'p = malloc (...); p = q;') . Potrei sbagliarmi. – detly