[질문] C 언어 고전적인 함수 정의 형식에 대한 지원

왜 고전적인 방법을 지원하고 싶으신지 궁금하군요 ?
어떤 특별한 이유가 있으신지요?
아니면 단지 예전 방식만을 처리하는 컴파일러에 대한 고려를 위해서 그러는 것인지 ?

C99 6.11 Future language directions 에는 다음과 같은 내용이 있습니다.

따라서 C99 이후의 표준에서는 언제든지 전통적인 함수 선언과 정의 방식이 사라질 수 있습니다.

게다가 원형 정의와 비원형 정의를 섞어쓰는 것은 매개변수 데이터형에 대해서 골치아픈 문제를 유발할 수 있습니다.

우선 원형으로 정의된 함수가 비원형 선언과 호환되기 위해서는 다음의 규칙을 만족해야 합니다. (C언어 펀더멘탈 p.552)

반대로, 비원형 정의와 원형 선언이 호환되기 위해서는 다음의 규칙을 만족해야 합니다.

이 두가지 경우에서는 모두 매개변수에 기본 인자 진급이라는 과정을 거치게 됩니다.

따라서 다음과 같은 코드들은 모두 잘못된 코드들입니다.

/* C언어 펀더멘탈 p.553 */
int func2();

int func2(short int a, float b, int *c) { /* ... */ }
/* short int a는 기본 인자 진급 과정을 거치면 int a가 되며, 적용되기 전의 데이터형과 호환되지 않는다. */

/* C언어 펀더멘탈 p.554 */
int func(a, b, c, d)
int a;
short int a, b[];
float d;
{
}

int func(short int a, short int b[], int c, double d);
/* int a에 기본 인자 진급 과정을 적용한 결과인 int a가 원형 선언에 나온 short int a와 호환되지 않는다. */

비원형 선언과 비원형 정의를 조합하는 경우에는 단지 호환되는 반환형만 가지면 되지만, 이 경우에는 비원형 선언을 사용할 때 가지는 문제점들을 모두 가지게 됩니다. 매개변수의 갯수와 타입을 검사하지 않지요.

위와 같은 점들을 고려해 볼 때, 일괄적으로 비원형 정의(전통적인 함수 선언 방식)을 사용하는 것은 여러가지로 불편해 보입니다.

제 생각에는 그냥 원형 선언과 정의를 사용하시고, 비원형 선언과 정의를 사용해야 되는 상황에 마주쳤을 때에만 #ifdef ... #endif 를 추가하는 것이 더 나은 해결책 같습니다(아니면 해당 컴파일러 버젼을 따로 만들던가;;). 원형 선언과 정의를 지원하지 않는 C 컴파일러는 이제 드물지 않습니까? 아무리 매크로를 사용한다고 해도 일일이 선언마다 코드를 추가하는 것 보다는 Makefile에서 컴파일러의 옵션을 다르게 지정해주는 쪽이 더 노가다를 줄일 수 있다 생각됩니다.

ps. 물론 이건 원론적인 얘기일 뿐이고 '무조건' 원형 선언과 정의를 지원하지 않는 C 컴파일러를 사용해야 되는 상황이라면 어쩔 수 없겠지요.

"구식 기술"로 표시해 둔 이유가 프로그래머에게 사용을 억제 시켜 추후
손쉽게 제거하기 위함입니다. 즉, 예전 C99 세미나에서도 언급한 적이
있지만, "구식 기술(obsolescent feature)" 이라는 용어가 단지 "구식인
기술" 을 의미하는 것은 아닙니다. 보다 공식적인 의미를 갖습니다.

덕분에 "구식 기술" 로 지정하고 10년이 지나도 없애지 못하고 있습니다.
C99에서도 살아 남았으므로 앞으로 최소 5년 정도는 더 버틸 것 같습니다.
ANSI C 라는 이름으로 표준이 발표된지 거의 15년이 지났습니다. 대체
얼마나 대단한 환경들이 현대 프로그래밍 언어가 다 쓰는 함수 원형을
제공하지 않기에 "지금" 개발되는 프로그램들이 구식 선언을 고려해야 하는
것인지 궁금합니다. 과거에 제작된 프로그램의 경우 유지보수 문제로
유지되고 있다지만 새로 개발되는 프로그램이 K&R C 를 고려할 이유가
있는지 심히 의심스럽습니다. 제 책에서도 이 논의에서 언급되었던 기법을
소개하고 있지만, 이는 사용을 장려하기 위함이 아니라 다른 곳에서 사용된
경우 이해를 돕기 위해서 다루고 있는 것 뿐입니다.

lsj0713 님은 그게 아니라고 설명하고 있는 것입니다. 내용을 다시 확인해
보시기 바랍니다. 이미 오해하고 계신 것처럼 원형/비원형을 함께 사용하기
위해서는 매개변수 데이터형에 더 신경을 쓰셔야 합니다.

purple% cat > t1.c
void f(float);

int main(void)
{
    f(3.14159f);

    return 0;
}
purple% cat > t2.c
#include <stdio.h>

void f(a)
float a;
{
    printf("%f\n", a);    
}
purple% cat > t.c
#include <stdio.h>

void f(float);

int main(void)
{
    f(3.14159f);

    return 0;
}

void f(a)
float a;
{
    printf("%f\n", a);
}
purple% gcc t.c
purple% ./a.out
3.141590
purple% gcc t1.c t2.c
purple% ./a.out
50.123535
purple% cc t.c
"t.c", line 13: identifier redeclared: f
        current : function() returning void
        previous: function(float) returning void : "t.c", line 3
cc: acomp failed for t.c

위에서 보시면 아시겠지만, gcc 는 참 똑똑한 컴파일러입니다. 하지만,
프로그래머의 잘못(undefined behavior)을 조용히 덮어주는 것만이 능사는
아니라는 것을 gcc 도 알 필요가 있다고 생각합니다.

f() 의 매개변수 데이터형을 float-double 쌍이 아닌 short int-int 쌍으로
테스트하면 분할 컴파일 하는 경우에도 제대로 동작하는 경우가 많습니다.
이유는 전달되는 인자 데이터형의 크기가 word 크기보다 큰가 아닌가 혹은
정수형인가 부동형인가의 문제였던 것으로 기억하고 있습니다. 즉, 실행
환경의 calling convention 이나 기타 다른 특성에 크게 의존하는 부분인
셈입니다.

word 단위가 아닌 실제 데이터형의 크기 그대로 전달하는 경우에도 byte
order 에 따라 little endian 이 더 너그럽게 받아들일 가능성이 큽니다
(이와 관련된 예를 제 책의 연습문제에 넣었던 것으로 기억합니다). 이
경우도 이것이 장점인지 단점인지는 생각하는 관점에 따라 다릅니다; 저는
개인적으로 단점이라고 주장하고 싶습니다.