C 매크로에서는 (0,0)가 {…}를 수행하는 동안 (0)을 선호해야합니까 (0)?

Question

고객은 최근 고용주의 C 코드베이스에 대한 정적 분석을 수행하고 결과를 제공했습니다. 유용한 패치 중에는 유명한 사람을 변경하라는 요청이었습니다. do { ... } while(0) 매크로 do { ... } while(0,0). 나는 그들의 패치가 무엇을하고 있는지 이해합니다 (시퀀스 연산자 사용 반품 두 번째 "0"의 값을 평가하므로 효과는 동일합니다. 그러나 왜 첫 번째 형식에서 두 번째 형태를 선호하는지 확실하지 않습니다.

두 번째 형태의 매크로를 선호 해야하는 합법적 인 이유가 있습니까?

Answer 1

글쎄, 나는 답을 얻을 것이다 :

두 번째 형태의 매크로를 선호 해야하는 합법적 인 이유가 있습니까?

아닙니다. 합법적 인 이유는 없습니다. 둘 다 항상 거짓으로 평가되며, 괜찮은 컴파일러는 어쨌든 어셈블리에서 두 번째 컴파일러를 첫 번째 컴파일러로 바꿀 것입니다. 어떤 경우에는 유효하지 않은 이유가 있다면, C는 그 이유가 나보다 더 큰 전문가에 의해 발견 될 정도로 충분히 길었습니다.

코드가 당신에게 올빼미 눈을 만드는 것을 좋아한다면 while(0,0). 그렇지 않으면, 나머지 C 프로그래밍 세계에서 사용하는 것을 사용하고 고객의 정적 분석 도구를 알려주십시오.

Answer 2

왜 그들이 사용 제안 할 수 있는지 추측합니다.

do { ... } while(0,0)

~ 위에

do { ... } while(0)

행동 차이가없고 둘 사이의 런타임 비용 차이가 없어야하지만.

내 생각에 정적 분석 도구가 while 더 간단한 케이스에서 상수로 제어되는 루프는 언제 0,0 사용. 고객의 제안은 아마도 도구로부터 많은 잘못된 긍정을 얻지 못할 것입니다.

예를 들어, 나는 때때로 상수에 의해 조건부 명세서를 제어하고 싶은 상황을 발견하지만, 컴파일러는 조건부 표현식에 대한 경고에 대해 불만을 제기 할 것입니다. 그런 다음 컴파일러가 불평을 중단하기 위해 약간의 후프를 뛰어 넘어야합니다 (가짜 경고가 마음에 들지 않기 때문에).

고객의 제안은 제가 그 경고를 조용히하는 데 사용한 후프 중 하나이지만 제 경우에는 제어하지 않았습니다. while 루프, 그것은 "항상 실패한"주장을 다루는 것이 었습니다. 때때로, 절대 실행해서는 안되는 코드 영역이 있습니다 (아마도 스위치의 기본 케이스). 그 상황에서 나는 항상 몇 가지 메시지로 실패하는 주장이있을 수 있습니다.

assert( !"We should have never gotten here, dammit...");

그러나 적어도 하나의 컴파일러 I를 사용하면 항상 False로 평가하는 표현식에 대한 경고를 발행합니다. 그러나 변경하면 다음으로 변경합니다.

assert( ("We should have never gotten here, dammit...", 0));

경고가 사라지고 모두가 행복합니다. 고객의 정적 분석 도구조차도 추측하고 있습니다. 나는 일반적으로 매크로 뒤에 점프하는 후프 비트를 숨 깁니다.

#define ASSERT_FAIL( x) assert( ((x), 0))

도구 공급 업체에 문제를 해결하도록 지시하는 것이 좋을 수도 있지만, 실제로 부울 표현으로 제어되는 루프를 실제로 진단하려는 합법적 인 사례가있을 수 있습니다. 도구 공급 업체가 그러한 변경을하도록 설득하더라도 내년에는 도움이되지 않도록 도구 공급 업체가 실제로 해결하는 데 도움이되지 않는다는 사실은 말할 것도 없습니다.

Answer 3

사용 while(0,0) Microsoft 컴파일러가 일정한 상태에 대한 경고를 생성하지 못하게합니다 (경고 C4127).

이 경고가 활성화되면 (예 : /W4 또는 /Wall),이 멋진 작은 트릭으로 사례별로 종료 될 수 있습니다 (이 다른 스레드를 참조하십시오).

편집 : Visual Studio 2017 이후 15.3, while(0) 더 이상 경고를 방출하지 않습니다 (참조. 일정한 조건부). 당신은 당신을 제거 할 수 있습니다 (0,0) !