87 매크로에서 키워드로 — bool·nullptr과 그 동료들

87.1 무엇이 승격됐나#

/* C23 에서 키워드로 승격된 것들 — 무엇이 달라졌나 */
#include <stdio.h>

/* 승격 전에는 이 줄들이 <stdbool.h>, <stdalign.h>, <assert.h> 를 요구했다 */
static_assert(sizeof(int) >= 4, "this code assumes int is at least 32 bits");

/* nullptr 은 자기 타입(nullptr_t)을 가진다 — 0 도 (void *)0 도 아니다 */
static void take_ptr(int *p) { printf("  pointer: %s\n", p ? "has a value" : "null"); }

/* 가변 인자에서 NULL 과 nullptr 의 차이가 드러나는 자리 */
static void print_all(const char *first, ...)
{
    printf("  %s ...\n", first);
}

int main(void)
{
    bool ready = true;                 /* _Bool 도 매크로도 아닌 진짜 키워드 */
    printf("sizeof(bool) = %zu, true = %d, false = %d\n", sizeof(bool), true, false);
    printf("ready = %d, !ready = %d\n", ready, !ready);

    /* bool 은 0 아닌 값을 전부 1 로 좁힌다 — int 로 흉내 낼 수 없는 성질 */
    bool  b = 42;
    int   i = 42;
    printf("bool b = 42 -> %d,  int i = 42 -> %d\n", b, i);

    int   x  = 7;
    int  *p  = &x;
    int  *np = nullptr;
    take_ptr(p);
    take_ptr(np);
    printf("nullptr compared with nullptr: %d,  compared with a pointer: %d\n", nullptr == nullptr, p == nullptr);

    /* typeof: 이름 없는 타입을 그대로 받아 적는다 */
    typeof(x) y = x * 2;
    printf("typeof(x) y = %d\n", y);

    /* constexpr: 진짜 상수 — 배열 크기에도, switch 라벨에도 쓸 수 있다 */
    constexpr int LANES = 4;
    int lane[LANES];
    printf("constexpr LANES = %d, array element count = %zu\n", LANES, sizeof lane / sizeof lane[0]);

    print_all("pass nullptr through the variable arguments", nullptr);
    return 0;
}

sizeof(bool) = 1, true = 1, false = 0
ready = 1, !ready = 0
bool b = 42 -> 1,  int i = 42 -> 42
  pointer: has a value
  pointer: null
nullptr compared with nullptr: 1,  compared with a pointer: 0
typeof(x) y = 14
constexpr LANES = 4, array element count = 4
  pass nullptr through the variable arguments ...

한 표로 정리한다. 왼쪽은 C17까지의 모습, 오른쪽이 C23이다.

헤더는 여전히 있고 포함해도 무해하다 — 표준이 옛 코드를 깨뜨리지 않는다는 원칙(69장의 gets 이야기)이 여기서도 지켜졌다. 다만 새로 쓰는 코드는 포함할 이유가 없다.

87.2 bool — 무엇을 막는가#

C에는 오랫동안 참·거짓 타입이 없었다. int로 흉내 냈고, 프로젝트마다 typedef int BOOL;과 #define TRUE 1이 굴러다녔다. C99가 _Bool을 들이고 <stdbool.h>가 예쁜 이름을 붙여 주었으며, C23이 그것을 키워드로 올렸다.

bool이 int와 다른 점은 이름이 아니라 변환 규칙이다.

• 0이 아닌 값은 모두 1로 좁혀진다. 예제의 bool b = 42;가 1을 찍은 것이 그것이다. int i = 42는 42 그대로다.
• 그래서 두 참을 비교해도 참이다. int 흉내 시절의 고전적 버그가 여기서 사라진다.

int a = isupper('A');      /* 구현에 따라 0 이 아닌 아무 값 */
int b = isupper('B');
if (a == b) { … }          /* 둘 다 참인데 값이 달라 거짓이 될 수 있다 */
if (a == 1) { … }          /* 더 나쁘다 */

bool a = isupper('A');     /* 여기서 1 로 정규화된다 */
bool b = isupper('B');
if (a == b) { … }          /* 안전 */

bool의 남은 함정 둘. 첫째, 비트필드에 bool을 쓰면 폭이 1이라도 잘 동작하지만 배치는 구현 정의다(47장). 둘째, bool 배열은 원소마다 한 바이트를 쓴다 — C++의 vector<bool>처럼 비트로 압축하지 않는다. 비트로 압축하고 싶으면 손으로 마스크를 짜거나(29장) <stdbit.h>의 도구를 쓴다.

87.3 nullptr — 이름 바꾸기가 아니다#

4장에서 널 삼형제를 구별했다. NULL은 매크로이고, 그 정의는 구현마다 0이거나 ((void *)0)이다. 이 자유가 실제 사고를 낳았다.

사고 1 — 가변 인자에서 크기가 어긋난다. 가변 인자 함수는 인자의 타입을 모르므로 넘어온 비트를 그대로 읽는다(63장). NULL이 0으로 정의된 구현 에서 execl("/bin/ls", "ls", NULL)이라 적으면 int 0이 넘어가고, 포인터가 8바이트인 기계에서는 위쪽 4바이트가 쓰레기로 남는다. 목록의 끝을 못 알아본 함수가 폭주하는 것이다. 그래서 옛 코드는 (char *)0이라 적어야 했다. nullptr은 언제나 포인터 크기라 이 문제가 없다.

사고 2 — 정수인지 포인터인지 흐려진다. NULL이 0인 구현에서는 foo(NULL)이 정수 0을 넘기는 것과 구별되지 않는다. _Generic(63장)으로 타입에 따라 갈래를 나누는 코드에서 이 모호함이 그대로 사고가 된다. nullptr은 nullptr_t라는 자기 타입을 가지므로 갈래가 분명하다.

사고 3 — C++과의 어긋남. C++은 2011년에 같은 이유로 nullptr을 먼저 들였다. 두 언어를 오가는 헤더(56장)에서 NULL의 의미가 갈리는 자리가 있었는데, C23이 같은 낱말을 채택해 그 틈이 좁아졌다.

규칙 몇 가지를 못박아 둔다. nullptr은 어떤 객체 포인터 타입으로도 변환되고, 함수 포인터로도 변환된다(64장). 두 nullptr끼리, 그리고 nullptr과 아무 포인터끼리 ==·!=로 비교할 수 있다. bool로 변환하면 거짓이다. 그러나 정수와는 비교할 수 없고, 정수로 변환되지도 않는다 — nullptr == 0은 진단 대상이다. “널 포인터는 정수 0과 같은 것”이라는 옛 직관을 언어가 끊어 놓은 셈이다.

87.4 나머지 승격과 새 낱말#

static_assert — 컴파일 시간에 조건을 검사하고, 어기면 번역이 실패한다. 예제 첫 줄이 그것이다. 실행 시간 assert(80장)와 성격이 다르다 — 이쪽은 “이 기계에서 이 코드가 성립하는가”를 묻는 도구라, 타입 크기·정렬·구조체 배치 가정을 코드에 못박는 데 쓴다. C23에서는 메시지를 생략할 수도 있다.

alignas·alignof — 4장에서 본 정렬을 언어로 다루는 낱말이다. 캐시 라인에 맞춰 배치하거나(13장의 거짓 공유 회피), 하드웨어가 요구하는 정렬을 맞출 때 쓴다.

thread_local — 갈래마다 따로 존재하는 변수를 만든다. 85장에서 본 공유의 문제를 공유하지 않음으로 피하는 도구다. errno가 실은 이 방식으로 구현된다(80장).

constexpr — 예제에서 본 대로 진짜 상수를 만든다. const int는 상수 식이 아니라서 배열 크기나 case 라벨에 못 썼고(24장), 그래서 그 자리는 오랫동안 #define의 몫이었다. constexpr은 그 자리를 타입 있는 이름으로 되찾아 준다 — 매크로가 언어로 승격되는 이 장의 주제가 여기서도 반복된다.

typeof — 식의 타입을 그대로 받아 적는다. GCC 확장으로 30년 넘게 쓰이던 것이 표준이 됐다. 매크로에서 임시 변수를 선언할 때 특히 요긴하다.

87.5 속성 — 타입이 담지 못하는 뜻을 적는다#

승격된 낱말들이 값과 타입의 자리를 되찾았다면, C23 이 함께 들인 속성(attribute)은 다른 자리를 채운다 — 「이 함수의 결과를 버리지 말라」, 「여기서 흘러내리는 것은 일부러다」처럼 타입에 담기지 않는 뜻이다. 그전까지 이런 말은 컴파일러마다 다른 확장(__attribute__((warn_unused_result)))으로만 할 수 있었다.

/* C23 의 속성 — 타입이 담지 못하는 「뜻」을 컴파일러에게 적어 두는 법 */
#include <stdio.h>
#include <stdlib.h>

/* ① nodiscard — 돌려준 값을 버리면 안 되는 함수.
   실패를 값으로 알리는 함수에 붙이면, 확인을 잊은 코드가 경고가 된다. */
[[nodiscard]] static int checked_add(int a, int b, int *out)
{
    if (b > 0 && a > 2147483647 - b) return 0;   /* 넘침: 실패 */
    *out = a + b;
    return 1;
}

/* ② maybe_unused — 빌드 구성에 따라 안 쓰일 수도 있는 것에 미리 붙인다 */
static void log_line([[maybe_unused]] const char *tag, const char *msg)
{
#ifdef VERBOSE
    printf("  [%s] %s\n", tag, msg);
#else
    printf("  %s\n", msg);
#endif
}

/* ③ noreturn — 돌아오지 않는 함수. 부르는 쪽의 뒷줄은 죽은 코드가 된다 */
[[noreturn]] static void die(const char *why)
{
    printf("  fatal: %s\n", why);
    exit(EXIT_FAILURE);
}

static const char *classify(int n)
{
    switch (n) {
    case 0:
        printf("  zero, and it keeps going\n");
        [[fallthrough]];          /* ④ 일부러 흘린다는 표시 */
    case 1:
        return "small";
    default:
        return "large";
    }
}

int main(void)
{
    int sum = 0;

    if (checked_add(2000000000, 2000000000, &sum))
        printf("  sum: %d\n", sum);
    else
        printf("  overflow refused\n");

    if (checked_add(2, 3, &sum))
        printf("  sum: %d\n", sum);

    log_line("main", "attributes carry intent, not types");
    printf("  classify(0) = %s\n", classify(0));
    printf("  classify(9) = %s\n", classify(9));

    if (sum != 5) die("checked_add lost a value");
    return 0;
}

  overflow refused
  sum: 5
  attributes carry intent, not types
  zero, and it keeps going
  classify(0) = small
  classify(9) = large

문법은 대괄호 둘이다 — [[이름]], 인자가 있으면 [[이름(인자)]]. 놓는 자리는 꾸미려는 대상 앞이고, 매개변수 하나에도 붙는다. 표준이 정한 것은 일곱이다.

앞의 다섯은 C++ 에서 건너온 것이고, 뒤의 둘은 C23 이 스스로 만든 것이다. 이 둘은 함수의 성질을 적어 최적화기에게 「같은 호출을 두 번 하지 않아도 된다」를 알리는 쪽이라, 다른 다섯과 결이 다르다.

87.5.1 속성은 무엇을 하는가 — 재어 본다#

속성은 코드가 하는 일을 바꾸지 않는다. 진단을 바꾼다. 세 개를 어겨 보면 이 기계의 두 컴파일러가 이렇게 말한다.¹

gcc:   ignoring return value of 'check', declared with attribute
       'nodiscard' [-Wunused-result]
       'old_check' is deprecated: use check instead [-Wdeprecated-declarations]
       'unsequenced' attribute ignored [-Wattributes]

clang: ignoring return value of function declared with 'nodiscard' attribute
       [-Wunused-result]
       'old_check' is deprecated: use check instead [-Wdeprecated-declarations]
       unknown attribute 'unsequenced' ignored [-Wunknown-attributes]

마지막 줄이 중요하다. ★ 두 컴파일러 모두 [[unsequenced]] 를 아직 구현하지 않았고, 그래서 그냥 무시한다. 표준에 있다고 컴파일러에 있는 것은 아니다 (19장에서 본 격차가 여기서도 나타난다). 그런데 무시해도 프로그램은 멀쩡히 돈다 — 그것이 다음 규칙 덕이다.

87.5.2 모르는 속성은 무시한다#

표준은 구현이 모르는 속성을 만나면 무시하라고 정한다. 속성 문법이 「괄호만 짝이 맞으면 아무 토큰이나」를 허용하는 것도 그래서다(부록 E). 이 한 줄이 속성을 이식성 있는 장치로 만든다 — 컴파일러 확장을 쓰려면 #ifdef 로 감싸야 했지만, 속성은 그냥 적어 두면 아는 컴파일러만 알아듣는다.

확장은 접두사로 적는다 — [[gnu::packed]], [[clang::overloadable]] 처럼. 이름 앞에 임자를 밝혀 두어 표준의 이름들과 부딪히지 않게 한 것이다.

87.6 기존 코드를 어떻게 옮기는가#

한꺼번에 바꿀 필요는 없다. 순서를 정해 두면 위험이 거의 없다.

1. 먼저 컴파일러 판을 정한다. -std=c23(또는 c2x)을 쓸 수 있는지, 대상 플랫폼 전부에서 되는지 확인한다. 하나라도 안 되면 아래 5번의 껍데기 전략으로 간다.
2. 자체 BOOL·TRUE·FALSE를 걷어낸다. 프로젝트 헤더의 typedef int BOOL;을 지우고 bool로 바꾼다. 이때 값 비교를 하던 곳이 없는지 함께 본다(위 반례) — 오히려 버그가 드러나는 자리다.
3. NULL을 nullptr로 바꾼다. 기계적 치환으로 대부분 끝나지만, 두 자리는 손으로 확인한다. 가변 인자 호출(여기서 실제 버그가 고쳐진다)과, NULL을 정수 0처럼 쓰던 코드(여기서 컴파일 오류가 난다 — 잘된 일이다).
4. _Static_assert·_Alignas·_Thread_local을 밑줄 없는 이름으로. 같은 것의 다른 표기이므로 위험이 없다. 이어서 이제 필요 없어진 <stdbool.h>·<stdalign.h> 포함을 정리한다.

5. 옛 판을 함께 지원해야 하면 껍데기를 한 자리에. 86장에서 한 것과 같다.

   #if __STDC_VERSION__ < 202311L
   #  include <stdbool.h>
   #  define nullptr ((void *)0)      /* 완전한 대체는 아니다 — 아래 주의 */
   #  define static_assert _Static_assert
   #endif

   이 nullptr 껍데기는 타입까지 흉내 내지는 못한다. _Generic 분기나 타입 검사를 하는 코드에서는 기대와 다르게 동작할 수 있으므로, 그런 코드가 있다면 껍데기 대신 판을 올리는 쪽이 옳다.

스물한 장에 걸쳐 표준 라이브러리와 최신 표준의 지형을 걸었다. 표준이 무엇을 약속하고 무엇을 약속하지 않는지, 어디가 미끄럽고 왜 그런지를 보았다.

이 부의 남은 두 장은 한 층 아래로 내려간다. 46장에서 “비싸다”고만 하고 지나간 자리 — 프로그램의 기억이 운영체제와 임베디드 칩에서 각각 어떤 배치로 놓이는지(88장), 그리고 그 배치의 힙 구역에서 할당자가 실제로 무슨 일을 하는지(89장)다. 그 두 장이 다음 부의 설계를 이해하는 바탕이 된다.