MISRA C 2012 가이드라인 표기 방식

• MISRA C 2012 가이드라인 표기 방식을 소개한다.

가이드라인 표기방식

• 가이드라인의 표기 방식은 다음과 같다.
  • Ident: 가이드라인의 식별자로서, 처음오는 숫자는 큰 주제마다 변경된다.
  • Requirement text: 가이드라인의 내용
  • Source ref: 가이드라인이 참고하는 다른 표준 문서
  • Category: 가이드라인의 중요성
  • Decidability: 가이드라인의 결정성
  • Scope: 가이드라인의 범위
  • Cxx: C언어 표준 버전(C90, C99)

Guideline Classification

• 가이드라인에 대한 설명의 수준에 따라, ‘rule(규칙)’과 ‘directive(지침)’으로 분류된다.
• ‘설명의 수준’이란 해당 가이드라인에 대하여 얼마나 상세하고 자세하게 설명되어 있는가를 의미한다.

Directive(지침)

• 코드가 directive 가이드라인을 준수하는지 검증할 때, 검증에 필요한 설명이 충분히 제공되지 않는다.
• 해당 검증 과정에서는 설계 문서 또는 요구사항 명세서와 같은 부가적인 정보가 필요하기 때문이다.
• 정적 분석 도구마다 directive 가이드라인을 다르게 해석할 수 있으므로 주의해야 한다.

Rule(규칙)

• 코드가 rule 가이드라인을 준수하는지 검증할 때, 검증에 필요한 설명을 상세하고 자세하게 제공한다.
• 해당 검증 과정에서는 코드 이외의 부가적인 정보(문서)가 필요 없다.

Guideline Category

• 가이드라인이 준수해야하는 중요성에 따라 ‘mandatory’, ‘required’, ‘advisory’의 category로 분류된다.

Mandatory guidelines

• Mandatory category는 필수적으로 준수해야 규칙으로, 예외를 허용하지 않는다.

Required guidelines

• Required category는 필수적으로 준수해야 하는 규칙, 정당한 사유가 있으면 예외를 허용한다.

Advisory guidelines

• Advisory guidelines는 준수하는 것을 권고하는 규칙으로, 선택적으로 적용한다.

Deviation(예외)

• 특정 경우에 따라서 예외적으로 MISRAC C 2012 가이드라인을 위배할 수 있다.
• 이러한 deviation은 코드나 파일로 문서화하여 기록해야 한다.
• 가이드라인을 위배하는 경우 소프트웨어의 안전성에 부정적인 영향을 주지 않는다는 근거와 이에 대한 자세한 설명이 문서에 명시되어야 한다.
• Deviation에 대한 자세한 설명 및 작성방법은 ‘MISRA Compliance:2016’에 기술되어 있다.
  ex) Deviation 예제 - 입출력
  메모리에 매핑된 I/O 포트에 접근하기 위한 일반적인 방법은 고정된 메모리 주소에 접근하는 것이다.
  하지만 이는 정수형 자료형을 포인터로 변환하는 작업을 수행하므로, MISRA C 2012 가이드라인을 위배하게 된다.

1
2

#define PORT (*(volatile unsigned char *)0x0002)
PORT = 0x10u;

Decidability of rule

• 어떠한 경우에도 ‘가이드라인 점검 결과를 보장할 수 있는가?’, ‘가이드라인 결과를 항상 보장 할 수 있는가?’ 즉, 가이드라인 결과를 항상 신뢰할 수 있는가를 의미한다.
• Directive(지침)을 제외한 rule(규칙) 가이드라인은 ‘decidability’ , ‘undecidablility’ 로 분류된다.

Decidability(결정성)

• 가이드라인 결과를 항상 보장할 수 있다. 즉, 가이드라인 결과가 항상 ‘예’ 또는’아니오’ 로 나오는 경우다.
  ex) 매번 실행할 때 마다 가이드라인이 영향을 받지 않는 경우
  Rule 11.3: depends on the source pointer and destination pointer types;

Undecidability(비결정성)

• 가이드라인 결과를 항상 보장할 수 없다. 즉, 가이드라인 결과를 ‘예‘ 또는 ‘아니오＇로 보장할 수 없다.
• 매번 실행할 때마다 시스템 속성이 변경되기 때문에, 가이드라인 결과가 시스템에 의존적으로 변경된다.
• 이로 인해서, 정적 분석 도구 마다 해당 가이드라인을 검증하는 방식이 다르기에 결과 또한 다를 수 있다. 비결정성 가이드라인의 경우 실제 위배이 아니라 가능성을 보고하는 방식으로 불확실성을 보고할 수 있다.
  ex) 매번 실행할 때 마다 시스템 속성이 변경되어 가이드라인이 영향을 받는 경우
  Rule 12.2: depends on the value of the right-hand operand of a shift operator;

Scope of Analysis

• 가이드라인 결과가 영향을 미치는 범위에 따라서 분류된다.

Single Translation Unit

• 위배한 가이드라인이 translation unit 범위 내 즉 전처리된 하나의 C언어 파일에서만 영향을 미치는 경우다.

System

• 위배한 가이드라인이 모든 코드 즉, 시스템 전체 범위에 영향을 미치는 경우다. 해당 가이드라인을 위배하였는가를 검사할 때에는 전체 코드 검증이 필요하다. 따라서 검증에 상당한 시간이 소요된다.
  ex) extern 함수 f는 다른 translation unit에 의해서 영향을 받게 된다.

1
2
3
4
5
6
7
8

extern void f ( uint16_t *p );
uint16_t y;
void g ( void )
{
	uint16_t x; /* x is not given a value */
	f ( &x ); /* f might modify the object pointed to by its parameter */
	y = x; /* x may or may not be unset */
}