프로세스 종료 함수 wait() 에 대해서 질문이 있습니다.
글쓴이: caihan / 작성시간: 수, 2008/10/01 - 1:52오후
wait 함수를 사용하기전에
sys/types.h
sys/wait.h
인클루드 한 후
int stat;
wait( &stat );
소스상에 위처럼 코딩하고 컴파일을 하면
error: incompatible type for argument 1 of `wait'
위와 같은 에러가 출력 됩니다.
재밌는 부분은 sys/wait.h 을 제거하고 컴파일 하면
warning: implicit declaration of function `wait'
라는 주의와 함께 실행파일이 떨어지고 동작도 잘됩니다.
이유가 멀까요... 어느 사이트를 보건 wait 함수의 인자는 int 형 포인터가 맞고 사용방법도 맞는데 인자의 타입이
잘못 사용되었다고 에러가 나오는 이유가 먼지 모르겠습니다.
제가 보기엔 리눅스 커널 2.6의 버그일지도 모른다는 생각도 해봅니다.
혹시 해결방법을 아시는 분은 공유좀 부탁드립니다.^^
Forums:
STAT(2)
STAT(2) System calls STAT(2) 이름 stat, fstat, lstat - 파일 상태를 얻는다 사용법 #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> int stat(const char *file_name, struct stat *buf); int fstat(int filedes, struct stat *buf); int lstat(const char *file_name, struct stat *buf);컴파일러가 좀 이상한 것 같기는 합니다만,
어지간하면 변수이름을 바꾸시죠.
원형(prototype) 선언을 제대로 하지 않고 코딩을 하면 버그가 숨어들 가능성이 커지게 된다는 것을 보여줄 뿐,
별로 재밌지는 않은 것 같은데요.
OTL
에러가 안나네요.
저는 에러가 안나네요...
ubuntu 7.10
gcc 4.1.3
kernel 2.6.22-15-generic
$ gcc -Wall -O2 t2.c -o t2
$ ./t2
$
#include <unistd.h> #include <stdio.h> #include <sys/wait.h> int main() { pid_t p; int stat; p = fork(); if (p != 0) wait(&stat); return 0; }없음
설령 sys/stat.h 를
설령 sys/stat.h 를 include 했다하더라도 에러가 나지않는 것이 정상입니다.
컴파일러가 개판이던가 예제 코드를 올리면서 실제 본인의 코드와는 다르게 올렸던가 했겠죠.
실제 코드를 추측해보면
#include <sys/types.h> #include <sys/stat.h> #include <sys/wait.h> int main() { int my_stat; wait(&stat); }이정도 ?
보통 이해할 수 없는 증상을 만나면 libc 나 컴파일러를 의심하던데,
이분은 특이하게도 커널을 의심하십니다.
자기 코드는 틀린데가 없다고 굳게 믿는 것은 피차일반이지만...
OTL
답글 정말
답글 정말 감사합니다. 본문의 소스 내용은 극히 필요한 일부분 이구요. 본문에서 돌아가는
wait 구문은 ProcessWait 라는 함수안에 모든 내용이 있습니다. 프로토타입 함수도 당연히 설정 했구요.
지역함수이고 int stat 는 지역변수 이므로 전혀 관계 없다고 봅니다. bushi 님 답변 감사합니다.
bushi님의 따끔한 충고 감사하고 제가 본문의 내용을 좀더 보충 햇어야 했는데 그러질 못했네요.
커널을 딱히 의심한건 아니고 저는 페도라 OS 를 말씀 드리고 싶었던 건데 제가 큰 실수를 한것 같습니다. 의미 전달에서요.
보통 리눅스는 헤더파일 오류로 컴파일이 되지 않는 경우가 종종 있습니다. 이런 부분을 말씀 드리고 싶었던 건데. 죄송 합니다.
noth 님 컴파일정보와 OS 정보 정말 감사 드립니다. 저는 페도라 쓰고 커널 2.6 인데
아무래도 크로스컴파일러 버전을 확인하는데 도움이 많이 될것 같습니다.
제가 지금 armgcc 로 크로스컴파일을 하고 있는데 좀던 알아봐야 겠습니다.
답변은 아닙니다만...
이런 류의 질문을 할 때에는 "긁어다가 C 파일로 저장하고 컴파일러 돌려보면 동일한 에러가 나는" 열줄 내외의 완전한 소스 코드를 첨부해서 질문을 하시는 쪽이 원하시는 답변을 얻을 확률이 훨씬 높아집니다. 사양이 특이한 경우 컴파일 명령어까지 적어주시면 금상첨화.
왜냐 하면 질문자가 원인이라고 의심하는 게 실제로는 원인이 아니고 범인은 코드의 전혀 딴 구석에 숨어있는 경우가 비일비재하거든요. 그래서 그냥 한두 줄 보여주고 "이게 매우 큰 소스코드의 일부인데요" 하면 보는 사람은 십중팔구 원인은 딴 거겠거니 하고 의심하게 됩니다. 정확한 정보가 없으니 정확한 답이 나오기 힘들죠. 아주 trivial한 케이스 말고는...
그뿐만 아니라 그렇게 "동일한 에러가 나는 열줄짜리 C 파일"을 만드는 과정에서 본인이 문제의 원인을 발견해서 질문할 필요가 없어져 버리는 확률도 꽤 높습니다. :P
* 범인은 분명 이 파일 안에 있다! - 김전일(??)
gcc2.9 glibc2.1 때부터
gcc2.9 glibc2.1 때부터 arm, mips, ppc 용으로 툴체인을 만들어 쓰고 있지만,
지역변수를 구분못하는 정도의 버그를 경험한 적은 없습니다.
간단히 테스트해 볼 수 있습니다.
#include <stdio.h> void a(int *a); void b(int *b); void a(int *b) { (*b)++; } void b(int *a) { (*a)++; } void test1(int a) { b(&a); printf("%d\n",a); } void test2(int b) { a(&b); printf("%d\n",b); } int main() { test1(1); test2(2); return 0; }OTL
댓글 달기