& 연산자는 절대로 널 포인터를 만들어 낼
수 없으며, 실패하지 않는 한 malloc() 함수도 널 포인터를
리턴하지 않습니다 (malloc()은 실패할 경우, 널 포인터를
리턴합니다. 그리고 이 것이 널 포인터의 쓰임새 - ``할당되지 않은''
또는 ``어떠한 것도 가리키지 않는''을 의미하는 특별한 포인터로
쓰이는 것 - 중 하나입니다.
널 포인터와 초기화되지 않은 포인터5와는 개념상 완전히 다릅니다. 널 포인터는 어떠한 오브젝트나 함수도 가리키지 않는 포인터이고, 초기와되지 않는 포인터는 어떤 값을 가지는 지 모르므로, 아무 오브젝트나 가리킬 수 있는 포인터입니다. 질문 1.30, 7.1, 7.31을 참고하기 바랍니다.
위에서 설명한 것처럼, C 언어는 각각의 포인터 타입에 따라 널 포인터가 존재합니다. 그리고 널 포인터의 실제 값은 각 타입에 따라 서로 다를 수 있습니다. 컴파일러가 각 타입에 따른 실제 값으로 변경해 주기 때문에 프로그래머들은 각 타입에 따라 서로 다른 널 포인터의 내부적인 값을 알 필요가 전혀 없습니다 (질문 5.2, 5.5, 5.6을 참고).
char *p = 0;
if (p != 0)
그러나, 함수의 인자로 포인터를 전달할 경우, 인자가 항상 포인터가 쓰일 곳(pointer context)으로 인식되지 않는다는 것을 주의해야 합니다. 즉, 컴파일러가 0을 널 포인터로 인식하지 못할 가능성이 있다는 뜻입니다. 이럴 때에는 널 포인터라는 것을 강제적으로 캐스팅을 써서 알려 주어야 합니다. 예를 들어, UNIX 시스템 콜인 execl은 가변 인자 리스트6를 받습니다. 이 함수는 인자의 끝을 알리기 위해서 널 포인터를 마지막으로 전달해야 합니다. 즉:
execl("/bin/sh", "sh", "-c", "date", (char *)0);
마지막 인자의 (char *) 캐스팅이 생략될 경우,
컴파일러는 이를 널 포인터로 인식하지 못하고 단순히 정수 0으로
인식합니다. (대부분의 UNIX 매뉴얼은 이 부분을 잘못 설명하고
있으니 주의해야 합니다.)
함수의 프로토타입(prototype)이 나온 경우, 인자 전달은 대입 연산으로 인식되기 때문에, 대부분 캐스팅을 할 필요가 없습니다. 왜냐하면 함수 프로토타입이 컴파일러에게 적절한 타입이 무엇이라는 것을 알려주기 때문입니다. 따라서 단순히 0만 전달해도, 컴파일러가 알아서 널 포인터로 바꾸어 줍니다. 그러나 가변 인자 리스트를 쓰는 함수의 인자는 프로토타입을 알더라도, 각각의 인자에 대한 타입을 알 수 없으므로 이런 함수의 인자로 쓰인 널 포인터에는 반드시 캐스팅을 써 주어야 합니다. (질문 15.3을 참고하시기 바랍니다.) 함수의 프로토타입이 있던 없던 상관없이, 무조건 함수 인자로 전달되는 널 포인터에 캐스팅을 하는 것이 혼동되지 않고 안전할 수 있습니다.
| 그냥 0을 써도 좋은 경우: | 캐스팅이 반드시 필요한 경우: |
| 초기화(initialization) | |
| 대입(assignment) | |
| 비교(comparison) | |
|
함수 호출,
프로토타입 있음 (prototype in scope) |
함수 호출, 프로토타입 없음 (no prototype in scope) |
|
고정된 인자 |
함수 호출에서 가변 인자 (variable argument) 사용 |
if (p)''라고 쓰는
것이 안전한가요? 만약 널 포인터의 실제 값이 0이 아닐 경우에는
어떻게 되는 건가요?
if (expr)
실제로 `expr'이 무엇이든지, 컴파일러는 위의 코드를
다음의 코드와 같은 것으로 봅니다.
if ((expr) != 0)
따라서 `expr'을 질문에서 주어진 `p'로 바꾸면,
`if (p)'가 `if (p != 0)'이 됩니다.
그리고 이 수식은 비교를 하는 문맥(comparison context)이기 때문에,
컴파일러는 0이 널 포인터 상수라는 것을 알고, 실제 널 포인터
값으로 변경해줍니다. 따라서 실제 널 포인터의 값이 0인지 아닌지는
알 필요가 전혀 없습니다.
불리언 부정(not) 연산자인 !는 다음과 같이 표현할 수 있습니다:
!expr is essentially equivalent to (expr)?0:1 or to ((expr) == 0)따라서 질문의 코드는 다음과 같이 해석할 수 있습니다.
if(!p) is equivalent to if(p == 0)그러므로 단축형(abbreviation)인
if (p)는 전혀 문제될 것이
없습니다. 그러나 어떤 사람들은 이런 식으로 코딩하는 것이 나쁜
습관이라고 말합니다 (물론 어떤 사람들은 좋은 습관이라고 말합니다.
질문 17.10을 참고하기 바랍니다).
질문 9.2를 참고하기 바랍니다.
#define) 있나요?
<stdio.h>를 포함한
여러 헤더 파일에 정의되어 있습니다). 어떤 경우 (void *)로
캐스팅되어 있는 경우도 (질문 5.6 참고) 있습니다.
따라서 정수 0과 널 포인터 상수인 0을 쉽게 구별하기 위해, 널
포인터가 오는 곳에 NULL을 사용하는 것입니다.
NULL을 쓰는 것은 단순히 스타일적인 문제입니다; 전처리기가 NULL을 0으로 바꾸어주므로, 컴파일러가 볼 때에는 모두 0으로 보게 됩니다. 따라서 함수 인자로 사용할 경우에는 0을 사용할 때와 마찬가지로 NULL도 캐스팅을 해줘야 할 필요가 있습니다.
질문 5.2의 표에서 0 대신에 NULL을 그대로 쓸 수 있습니다 (캐스팅하지 않는 NULL은 캐스팅하지 않는 0과 같기 때문입니다).
그러나 NULL은 반드시 포인터가 쓰이는 문맥에서만 쓰여야 합니다. 질문 5.9를 참고하기 바랍니다.
프로그래머가 널 포인터를 쓸 경우, 0을 쓰던지 NULL을 쓰던지에 상관없이, 실제 컴퓨터의 내부적인 널 포인터 값을 만들어내는 것은 컴파일러의 역할입니다. 따라서 컴퓨터에서 내부적으로 표현되는 널 포인터 값이 0이 아닌 다른 값이더라도 NULL은 무조건 0으로 정의되어 있습니다. 즉 컴파일러는 포인터 문맥에 쓰인 0은 자동으로 널 포인터 값으로 변경해 줍니다. 질문 5.2, 5.10, 5.17을 참고하기 바랍니다.
#define NULL ((char *)0)
함수 인자로 NULL을 전달할 때, 캐스팅하지 않아도 되지 않을까요?
FILE *fp = NULL;
그러나 ANSI C는 NULL을 다음과 같이 정의하는 것을 허락하고 있습니다:
#define NULL ((void *)0)
그러나 NULL을 위와 같이 정의하는 것은 (homonegeous pointer를 쓰는 컴퓨터에서만 도움을 줄 수 있습니다만) NULL을 잘못쓰는 문제를 어느 정도 해결해 줄 수 있습니다 (예를 들어 ASCII NUL 문자가 와야 하는 곳에 NULL을 쓰는 경우; 질문 5.9 참고).
다른 종류의 0이 필요한 곳에는 만약 그게 제대로 동작한다 할지라도
NULL을 쓰면 안됩니다. 왜냐하면 그럴 경우, 잘못된 스타일에 관한
메시지가 발생하기 때문입니다. (게다가 ANSI는 NULL을
((void *)0)으로 정의할 수 있도록 하고 있으므로), 포인터가
쓰일 수 있는 모든 곳에 NULL을 쓸 수 있는 것도 아닙니다.
특히 ASCII null 문자 (NUL)이 쓰일 곳에 NULL을 쓰면 안됩니다.
꼭 매크로를 써야 한다면 다음과 같이 따로 정의해서 쓰는 것이
더 낫습니다:
#define NUL '\0'
#define Nullptr(type) (type *)0
이게 좋은 습관일까요?
#define)되어 있습니다.
(질문 5.4 참고).
"")을 나타내는
다른 말로, C 언어에서 `널 문자열'이라는 용어를 쓰는 것은
혼동을 가져옵니다. 비어있는 문자열은 널 문자('\0'을
말하는 것이지, 널 포인터와는 상관 없습니다.
이 글에서는 ``널 포인터(null pointer)''라는 용어를 위의 1번의 목적으로 사용합니다. 3 번의 목적으로는 0이나 ``널 포인터 상수''라는 표현을 쓰며, 4 번의 목적으로 ``NULL''을 사용합니다.
if (p == 0)''이라는
코드는 0을 포인터형으로 변경하는 것이지만 p를 정수형으로
변환하는 것처럼 보일 수도 있습니다. 마지막으로 여러가지로 쓰이는
(질문 5.13 참고) ``null''이라는 용어를 건성으로 보는 경향이 있습니다.
C 언어에서 이런 혼동을 없애기 위한 방법으로는 널 포인터 용도로 쓰기 위한 (Pascal의nil과 같은) 키워드(keyword)를 만드는 것을 생각해 볼 수 있습니다. 그러면 컴파일러는 ``nil''을 적절한 널 포인터로 바꾸어 줄 수 있을 것이며, 널 포인터가 올 수 없는 곳에서는 경고를 발생해 줄 수 있을 것입니다. 그러나 현재 C 언어에서 널 포인터를 나타내는 키워드는 ``nil''이 아니라 ``0''입니다. 그리고 널 포인터가 올 수 없는 곳에 0이 쓰이면, 에러가 발생하는 것이 아니라 정수 0으로 해석된다는 것이 다릅니다.
게다가 널 포인터에 대해 잘 이해하기 위해, 실제로 내부적으로 표현되는 널 포인터의 값을 (0인지 아닌지에 대해) 알 필요가 전혀 없습니다. 단순히 널 포인터가 내부적으로 0으로 표현된다고 생각한다고 해서, 코드를 작성하기 쉬워지는 것도 아닙니다. (잘못된 calloc()에 대한 설명을 질문 7.31에서 참고하기 바랍니다.) 그리고 널 포인터가 0이라고 해도 포인터의 크기가 타입에 따라 달라질 수 있기 때문에 여전히 함수 호출에서 캐스팅을 해야 합니다. (만약 질문 5.14에서 말한 것처럼 ``nil''이 널 포인터로 쓰일 수 있다면 널 포인터가 0인지 아닌지에 대한 논쟁 자체가 의미없는 것이 될 것입니다.)
char *)보다 워드 포인터 (int *)가
크기가 더 작습니다.
Data General사의 Eclipse MV 시리즈는 기계 수준에서 세 가지의
포인터 타입을 제공합니다 (워드, 바이트, 비트 포인터). C 언어에서는
두 가지 형태를 사용하며 char *와 void *는
바이트 포인터로, 나머지 포인터는 워드 포인터로 구현됩니다.
어떤 Honeywell-Bell 메인프레임에서는 널 포인터 값으로 06000을 사용합니다.
CDC Cyber 180 시리즈는 링(ring), 세그먼트, 옵셋 부분으로 이루어진 48 비트 포인터를 사용하며, (링 11의) 대부분의 사용자는 널 포인터로 0xB00000000000를 사용합니다. 오래된 CDC는 1의 보수(one's complement) 방식을 사용하며, 잘못된 주소를 포함한 모든 데이터의 예외 상황에 모든 비트가 1인 수치를 사용합니다.
오래된 HP3000 시리즈는 위에서 언급한 다른 기계들처럼 char *,
void *에 대한 포인터와 나머지 포인터들을 바이트 어드레싱과
워드 어드레싱을 써서 구현하며, 두 어드레싱이 서로 다른 방식을
사용합니다.
Symbolics Lisp 컴퓨터에서는, (tagged architecture), 아예 수치로
표현되는 포인터를 제공하지 않습니다. C 널 포인터는 <NIL, 0>으로
구현됩니다. (기본적으로 <object, offset>을 사용함.)
8086 계열의 프로세서 (PC 호환) 에서는 `메모리 모델'에 따라 16 비트 데이터 포인터와 32 비트 함수 포인터를 쓸 수 있습니다. 또는 32 비트 데이터 포인터와 16 비트 함수 포인터를 쓸 수 있습니다.
어떤 64 비트 Cray 컴퓨터에서는 int *를 한 워드의 하위 48
비트로 표현하며, char *는 나머지 상위 16 비트를 옵셋으로 써서
표현합니다.
어떤 디버거들은 데이터 와치포인트(watchpoint)를 주소 0에 설정할 수 있도록 해 줍니다. 또는 아예 주소 0 근처의 약 20 바이트 정도를 다른 곳에 복사해두고 주기적으로 비교해서 변경되었는지를 검사할 수도 있습니다. 질문 16.8을 참고하기 바랍니다.