sizeof(<var>) vs sizeof(<type>)

여러분은 정말로 주의해야 합니다 : 배열과 포인터의 차이 [...] 변수가 simple (int, long, ...)이면 'sizeof (variable)'를 사용하고 변수가 complex (struct, pointer-to-pointer)라면 'sizeof (the_actual_type )`를 사용해야 합니다.

내부 범위에서 할당 된 포인터에 접근 하는것은 ** 정의되지 않은 동작 **입니다.

https://github.com/neovim/neovim/pull/656#issuecomment-41905534

TODO: legacy Vim struct hack에 대한 토론 링크

• signed 변수를 unsigned로 변환 (-Wconversion에 의해 체크되지 않은 파일들에서)

부호있는 유형과 부호없는 유형을 선택하는 동안 유의해야 할 몇 가지 중요한 사항이 있습니다.

첫째, unsigned overflow가 정의되고 ** signed overflow는 정의되지 않습니다. 이것은 불행한 역사적 실수로서, signed 정수가 가지고 있는 것이 무엇인지 확실하지 않은 때로부터 유래합니다. C 표준은 각 표현이 다른 동작을 하기 때문에 signed 정수가 overflows 될 때 어떤 일이 발생할지를 지정해서는 안되며 / 지정할 수 없어야 한다고 결정했습니다. 현대에서는 부호있는 정수가 항상 2의 보수 형식으로 표현됩니다. 이 형식은 많은 장점이 있습니다.

흥미로운 점은 gcc와 clang이 passing the -fwrapv flag을 사용하여 signed overflow를 정의된 대로 볼 수 있게 하는 것입니다. 이것은 불행하게도 비표준 입니다.

정의된 것과 정의되지 않은 것은 무엇을 의미합니까? unsigned 정수가 overflows되면 0으로 되돌립니다. 그러나 signed 정수가 overflows되는 경우 $ 신 (神)은 일어날 일만 알고 있습니다. 더 구체적으로 : 우리는 2개의 보수 signed 정수가 overflow 될 경우 어떤 일이 벌어지는지 알 수 있지만 컴파일러는 표준이 정의되지 않았기 때문에 원하는대로 할 수 있습니다. 결과적으로, 최적화 컴파일러는 종종 unsigned 정수가 overflow 할 수 없다(mahkoh의 정의되지 않은 동작 예제를 여기에 삽입하십시오)라고 가정하고 일부 분기 또는 비교를 최적화 합니다. 이 동작으로 인해 루프가 영구적으로 실행될 수 있습니다. 조건이 주의 깊게 쓰여지지 않는다면, unsigned 정수의 잘 정의된 wraparound overflow가 비 종결 루프 (non-terminating loops)를 일으킬 수 있다는 점에 유의해야 합니다. '(U) INTX_MAX / MIN`은 여러분의 친구입니다.

따라서 unsigned 산술은 over 및 underflow를 정의했으므로 우수하다고 판단 됩니다. 그러나 그것은 항상 사실이 아닙니다. 많은 언어 (예 : Java)가 unsigned 유형을 노출시키지 않는 데는 좋은 이유가 있습니다. 오류를 발견하기가 어려울 수 있습니다. *흐름의 가장 일반적인 형태는 unsigned 산술에서의 underflow입니다. unsigned int num = 0;에서 1을 뺀 것은 UINT_MAX로 감싸줍니다. 이것은 생각하는 것보다 훨씬 더 일반적입니다. 이런 이유만으로도 보통 int를 uint32_t/size_t/... 또는 다른 unsigned 타입 대신에 루프 카운터로 사용하는 것이 더 안전합니다. **. 숙련 된 프로그래머라도 일부 경우 underflow가 발생하지 않는 unsigned 코드를 작성하는 것을 피하기가 어렵습니다. 그래서 ** 문제 ** : 올바른 서명 된 코드를 작성하는 것이 더 쉽지만 'size_t'와 비교할 때 casts를 사용해야 합니다. (sizeof, strlen 등의 반환 유형이므로 자주 발생합니다). casts는 추악하기 때문에 가능하면 피해야 합니다. 그러나 우리는 어디에서나 그것들을 피할 수는 없습니다. 가끔 trade-off가 이루어져야 합니다. 예제는 이전 -Wconversion PRs를 참조하십시오.

결론:

• underflow가 발생할 가능성이 있거나 문제의 루프가 작으면 (정확하게 '2 ^ 31'항목보다 작음), 루프 앞에 signed 산술과 guards를 사용하십시오.
• 만약 overflow의 가능성이 있다면, unsigned 산술과 가능하다면 guards를 사용하십시오.
• underflow와 overflow의 가능성이 있는 경우 매우 조심하십시오.

char,short,int,long 외에도 (u) intX_t와 친구들을 사용해야 할까요? ...

• size_t: ...
• rsize_t :이 형식은 C11 표준에서 새로 추가 되었기 때문에 사용할 수 없지만 그 뒤에있는 추론과 사용법은 흥미롭습니다. rsize_t 타입의 변수가 가질 수 있는 실제 최대값은 RSIZE_MAX 대신 ** less ** 입니다. 즉, 작업을 계속하기 전에 val <= RSIZE_MAX인지 확인하고 유용하게 사용할 수 있습니다. 첫번째 유용한 속성은 :RSIZE_MAX에 대한 값은 대개 너무 커서 어쨌든 유용하지 않습니다. rsize_t가 64 비트라면 누가 막대한 양의 메모리를 할당하려고 합니까? 논란의 여지는 있지만 작업 수행을 거부하는 것이 좋습니다. 두 번째 유용한 속성은 unsigned 산술이 underflow 문제에 덜 취약하게 만드는데 좋습니다. rsize_t val = -4은 감싸졌기 때문에 RSIZE_MAX보다 클 것입니다. RSIZE_MAX에 대해 bounds-check를 하는 함수는 그 값을 거부합니다. 이것은 cast(rsize_t는 서명이 없어야 함)없이 unsigned 코드와 상호작용할 수 있는 좋은 방법인 것처럼 보이며 signed 산술의 안전 이점을 여전히 가지고 있습니다.

Neovim과 같이 코드베이스를 생성, 유지 및 변환하는 동안 도움이 되는 유용한 도구가 있습니다. 일부 기사 :

• Clang 및 libTooling을 사용한 최신 소스 - 소스 변환
• 빠른 정수 overflow 검사를 작성하는 방법은 무엇입니까?
• include-what-you-use
• size_t가 필요한 곳에 고집스럽고 무식한 int 사용