제 경우는 HP 서버에서 주로 개발을 하고 가끔 SUN 장비를 다루는데, SUN장
비에 따라오는 C 컴파일러와 라이브러리의 사용에는 HP와는 다르게 약간 주
의가 필요하더군요. 다음 예를 보시면...
 #include <stdio.h>
#include <stdlib.h>
void main() {
     char* ptrString = NULL;
    printf("테스트 : %s", ptrString);
}
 이 코드를 SUN 장비에서 컴파일하고 실행시키면 어떻게 될까요? 한번 해 보
세요. 아마 CORE DUMP가 날 겁니다. 이유는 ptrString이 널 포인터이기 때문
인데, SUN쪽의 라이브러리의 경우는 널 포인터를 문자열이 지정되지 않은것
으로 판단하지 않고 진짜로 메모리상의 0x00000000 번지로 받아들입니다. 보
통 이 주소은 다른 프로세스가 사용하고 있겠죠. 그래서 "남의 땅 건드리지
마" 하고 위의 프로그램을 죽이게 됩니다.
 HP쪽의 C 컴파일러는 위와 같은 경우 예외처리를 하도록 하는 옵션이 있는
데, SUN C 컴파일러에서는 아직 못 찾았습니다(없는건지도 모릅니다).
 또 하나요. 이번에는 변수의 scope 문제입니다.
 #include <stdio.h>
#include <stdlib.h>
 char* getString();
 void main() {
     printf("테스트 : %s", getString());
 }
 char* getString() {
    char retValue[10];
     strcpy(retValue, "TEST");
     return retValue;
}
 위의 소스를 돌리면 어떻게 될까요? SUN에서는 널스트링이 출력됩니다(다행
이 제 경우 죽지는 않았습니다.). HP에서는 TEST라고 출력됩니다. 원래대로
하자면 getString함수가 리턴하는 retValue 배열은 getString함수의 수행이
끝나면 사라져도 할 말이 없죠. 원래 지역변수로 선언되었으니까요. 그래서
printf 함수로 출력하는 시점에서는 데이터가 없어질 수가 있습니다. SUN장
비의 경우 아니나다를까 기대를 저버리지 않고 데이터가 사라졌습니다. HP
의 경우는 메모리상의 데이터를 웬만하면 최대한 보존해 주는 쪽이라 그런
지 지역변수에 저장된 데이터가 남아 있더군요.
 SUN에서 돌리려고 이렇게 고쳤었습니다. 올바른 코드인지는 잘 모르겠지만,
이렇게 메모리를 할당해 놓으니 이 영역은 scope rule의 영향을 받지는 않더
군요. 헌데 이런식으로 동적인 메모리할당을 계속하다 보면 시스템 heap만
자꾸 축내서 자원 부족 사태(윈도우에서 자주 보는)가 나는건 아닌지 모르겠
네요.
 char* getString() {
    char* retValue;
     retValue = (char*)malloc(10);
     strcpy(retValue, "TEST");
    return retValue;
}
 SUN의 경우 메모리 관리가 상당히 tight하므로 메모리 관리쪽에 주의를 하시
는게 좋을듯 싶습니다.
 :
: 답변 감사해요^^*
: 그냥 궁금해서요...
:
: : /usr/java/jre/sparc/native_threads/java 를 실행시키는거군요.
: :
: : 뒤의 -Dpropdir=/usr/sadm/l 는 java 가상머신에게
propdir=/usr/sadm/l 이
: : 라는 시스템 변수값을 넘겨준다는 뜻이구요.
: :
: : 상위 디렉토리로 되돌아가는 의미인 .. 가 너무 많이 쓰여서 헛갈리신
듯 하
: : 네요. (설치 스크립트가 자동으로 만들어주는 절대PATH에 이런것들이 보
이던
: : 데...)
: :
: : 근데 SUN sparc 에서 작업하시나요? 웬 sparc이 PATH에 보일까...
: :
: : :   /usr/java/bin/../jre/bin/../bin/sparc/native_threads/java -
: : Dpropdir=/usr/sadm/l
: : :
: : : --
: : : id:jinamomo
:
: --
: id:jinamomo