[C언어] Implementation-Defined Behaviour

키워드

Undefined Behaviour, Unspecified Behaviour, Implementation-Defined Behaviour

ㅤ

프로그램의 이식성

A 환경에서 실행하는 프로그램을 B 환경에서 실행하려고 할 때, 전환 과정에 노력이 덜 필요할수록 이식성이 좋다고 표현함. 이식성을 표현하기 위해 3가지 Behaviour(=Behavior)를 정의.

ㅤ

ex) Intel 맥에서 돌아가던 프로그램을 ARM 맥에서 돌리는 과정이 쉬운가?

ㅤ

Undefined Behaviour

코드가 어떻게 동작할지 보장하지 못하는 상태. 지금은 잘 동작하는 것처럼 보여도 다른 상황에서는 문제가 발생할 수 있다. 이식성 측면에서 가장 위험한 요소.

ㅤ

Undefined Behaviour 의 경우, 컴파일러가 컴파일 자체를 실패시키는 경우도 있고, 경고만 주고 넘어가는 경우도 있다. 런타임에서도 어떻게 동작할 지 정의되지 않았음.

이러한 상황에서 어떤 동작을 할 지 표준에 나와있지 않기 때문에, 동작을 결정하는 것은 오롯이 컴파일러의 몫임.

// 이게 유효하게 실행이 될 지도 의문임
int a = 5 % 0;
int b = 3 / 0;

int arr[5];
arr[10] = 42;

int *p = NULL;
*p = 10;

int i = 5;
printf("%d %d\n", ++i, i++);

ㅤ

Unspecified Behaviour

표준이 1개 이상의 동작 가능성을 제공하고 있어, 시스템마다 어떻게 동작할 지 표준에서 강요하지 않는 상태. 어떤 방식으로 구현할 지에 대해 문서화할 의무가 없는 경우를 말함.

→ 느슨한 코드인 느낌. 이런 코드를 많이 작성한 것도 이식성 측면에서는 좋지 않은 코드가 될 가능성이 높다.

ㅤ

컴파일러마다 / 상황마다 실행 순서나 처리 방법이 다를 수 있어 문제가 발생할 수 있다.

ㅤ

a = 5;
c = (b = a + 2) - (a = 1);
// 실행의 결과로 c가 6이 될 것인가? 아니면 2가 될 것인가?

a + b + c
// (a + b) + c 일지 아니면 a + (b + c) 일지

func(f1(), f2(), f3())
// f1, f2, f3 간의 실행 순서는 정해지지 않았음

ㅤ

Implementation-Defined Behaviour

표준은 1개 이상의 동작 가능성을 제공함(=Unspecified Behaviour). 그런데, 특정 시스템마다 표준을 참조해 어떤 동작을 할 지를 미리 정해서 이를 문서화해 제공해야함.

ㅤ

short, int, long 자료형을 필요로 하며, 위 자료형들은 각각의 특정 범위를 담당할 것.
int의 표현범위는 short 보다 작지 않을 것.
long의 표현범위는 int 보다 작지 않을 것.
// 16bit 시스템에서는 int가 2byte / 32bit 시스템에서는 int가 4byte 

char c = 200
// 플랫폼에 따라 char를 signed / unsigned로 바라봄

int x = -1;
unsigned int y = x >> 1;
// 컴파일러의 구현에 따라 다르게 동작할 수 있음.

ㅤ

예시

https://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html#C-Implementation

https://learn.microsoft.com/en-us/cpp/c-language/implementation-defined-behavior?redirectedfrom=MSDN&view=msvc-170

참고자료

https://hell0computer.tistory.com/5

https://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html#C-Implementation

https://learn.microsoft.com/en-us/cpp/c-language/implementation-defined-behavior?redirectedfrom=MSDN&view=msvc-170