He encontrado un "error" en mi código (el único ;-) que desencadena por eso, y que no es detectado por -Wall
. Lo cociné al siguiente
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);
}
Esta es una implementación relativamente sencilla de una lista vinculada, pero esto no es importante aquí. La variable myhead
no se utiliza en una aplicación de sentido común del término, pero para el compilador se usa porque dentro del inicializador se toma la dirección de un campo.
clang
análisis correctamente esto como
/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.
Editar: He encontrado otro que también detecta la proliferación memoria de pila
char const* myBuggyFunction(void) {
return (char[len + 1]){ 0 };
}
Esto no es detectado por gcc
, open64
o clang
con -Wall
, pero por clang
con --analyze
.
Hace el trabajo, gracias :) Debo decir que inventé las pérdidas de memoria más obvias y creativas que pude imaginar, y las dejé pasar a todas. Claramente, sabe lo suficiente como para saber que lo estaba probando. – detly
@detly: ha sido divertido, aprendido clang por :) para mi curiosidad ¿qué son las filtraciones en un contexto de análisis estático? –
Bueno, no estoy 100% seguro, pero tenía la impresión de que muchas herramientas de análisis estático, incluido el clang, pueden detectar posibles problemas de memoria de tiempo de ejecución (como 'p = malloc (...); p = q;') . Podría estar equivocado acerca de eso. – detly