2010-07-21 7 views
3

클래스/구조체 패딩의 매우 귀찮은 부작용이 Purify으로 발생했습니다. 예 :클래스/구조체 패딩에 대한 Purify의 Uninit Memory Read (UMR)

struct something { 
    int field1; 
    char field2; 
}; 

/* ... */ 

struct something smth, smth2; 
smth.field1 = 1; 
smth.field2 = 'A'; 

smth2 = smth; 

마지막 행은 3 바이트의 초기화 된 메모리가 액세스된다는 UMR 경고를 트리거 할 가능성이 높습니다. 이것은 분명히 거짓 긍정입니다. 구조체의 마지막 3 바이트에는 사용자 데이터가 없습니다. 단지 패딩입니다.

종종 경고는 매우 빠르게 로그 파일을 채워서 다른 실제 문제를 보는 것을 어렵게 만듭니다.

누구나 오 탐지를 억제하는 방법을 알고 있습니까?

+0

C++의 경우 실제로 다른 가능한 솔루션을 찾았습니다. 심지어 구조체가 기본 및 복사본 c'tors를 구현합니다. 복사 생성자 구현은 분명히 실제 필드 만 복사하고 절대 패딩을 건드리지 않지만 복사 생성자는 구조 할당의 컴파일러 최적화를 방해하는 것 같습니다. – Dummy00001

답변

0

나는 퓨리와 경험이 없지만, 아마도 명시 적으로 첫번째 구조체를 초기화하는 것은이 경고 제거합니다

struct something smth = {0}; 
struct something smth2; 

내가 당신의 구조체는 블록 범위 (파일 없음)가 있다고 가정합니다. 파일 범위가있는 경우 0 초기화가 암시 적입니다.

+0

이 방언은 무엇입니까? gcc/g ++ 4.1.2에서는 경고없이 컴파일되지 않습니다. – bstpierre

+0

아, 내 gcc 경고 질문에 대한 대답은이 질문에 (또한 OP의 질문에 대한 힌트를 제공합니다) : http://stackoverflow.com/questions/894300/when-zeroing-a-struct-such-as-sockaddr -in-sockaddr-in6-addrinfo-before-use – bstpierre

+0

@schot : C와 비슷한 구조체에서는 괜찮지 만, 작동하지 않는 C++ 구조체 (생성자가있는 구조체)에서는 괜찮습니다. 그리고 네, 블록 범위 (스택의 변수) 또는 힙입니다. – Dummy00001