मैं एक "बग" मेरी कोड में (केवल एक ;-) कि कि द्वारा चलाता है पाया है, और उस -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 };
}
यह -Wall
साथ gcc
, open64
या clang
नहीं पहचान पातीं पाया है, लेकिन द्वारा clang
--analyze
के साथ।
स्रोत
2010-08-15 10:06:40
क्या नौकरी, धन्यवाद :) मुझे कहना होगा, मैं सबसे स्पष्ट और सबसे रचनात्मक खूनी स्मृति लीक के साथ आया था, जिसे मैं सपना देख सकता था, और यह उन सभी को पास करने देता था। स्पष्ट रूप से यह जानना पर्याप्त है कि मैं इसका परीक्षण कर रहा था। – detly
@detly: मजेदार रहा है, इसके द्वारा झुका हुआ सीखा :) मेरी जिज्ञासा के लिए स्थिर विश्लेषण के संदर्भ में लीक क्या हैं? –
वैसे मैं 100% निश्चित नहीं हूं, लेकिन मैं इस धारणा के तहत था कि क्लैंग समेत कई स्थिर विश्लेषण उपकरण संभावित रनटाइम मेमोरी समस्याओं का पता लगा सकते हैं (जैसे 'p = malloc (...); p = q;') । मैं इसके बारे में गलत हो सकता था। – detly