Я нашел "ошибку" в своем коде (единственную ;-), которая срабатывает из-за этого, и которая не обнаруживается -Wall
. Я приготовил это до следующего
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);
}
Это относительно простая реализация связанного списка, но здесь это не важно. Переменная myhead
не используется в обычном применении термина, но для компилятора она используется, т.к. внутри инициализатора берется адрес поля.
clang
правильно анализирует это как
/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.
Редактировать: я нашел еще один, который также обнаруживает распространение памяти стека.
char const* myBuggyFunction(void) {
return (char[len + 1]){ 0 };
}
Это определяется не gcc
, open64
или clang
с -Wall
, а clang
с --analyze
.
person
Jens Gustedt
schedule
15.08.2010