91 proven이란 무엇인가 — 그리고 시작하기

91.1 왜 이 라이브러리가 있는가#

앞 장이 반세기째 되풀이되는 다섯 가지 결함을 실제로 도는 코드로 보였다. 이 장부터 그 각각에 대한 답을 본다. 그런데 도구를 꺼내기 전에 그 도구의 출처와 한계를 먼저 밝히는 것이 순서다. 이 절은 네 가지를 차례로 적는다 — 왜 만들었는가, 무엇을 다르게 하려는가, 무엇이 검증되었는가, 그리고 아직 무엇이 검증되지 않았는가.

왜 만들었는가. 저자가 C 로 프로그램을 만들며 같은 자리에서 반복해서 미끄러졌기 때문이다. 그 자리들은 이 책이 이미 하나씩 짚어 온 것들이다 — 표현의 한계(6·28장), 소리 없이 일어나는 변환(29장), 기억의 수명(36·44장), 값으로 오지 않는 오류(38·79장), 그리고 계약이 문서에만 있는 표준 라이브러리 함수들(69–70장). 한 번 데면 요령이 생기지만, 요령은 사람이 지치면 무너진다. 그래서 요령 대신 부품으로 만들어 두려 한 것이 시작이다.

무엇을 다르게 하려는가. 최근 시스템 프로그래밍이 향해 온 방향 — 오류를 값으로 다루기, 경계와 수명을 타입에 적기, 할당자를 인자로 받기, 문자열을 UTF-8 로 못박기, 부품을 작게 잘라 검사 가능하게 두기 — 를 C23 로 구현해 보려는 시도다. 새 언어로 옮겨 가면 얻는 것들을, 옮겨 갈 수 없는 자리에서도 얼마나 가져올 수 있는지 재 보는 실험에 가깝다.

책 안에서의 위치. proven 은 표준 C 를 대신하지 않고, 이 책이 앞의 여든아홉 장에서 가르친 것을 무르지도 않는다. 문제는 앞에서 proven 없이 설명했고, 여기서는 그중 하나의 해법을 볼 뿐이다. 다른 해법을 고르거나 직접 짜도 좋다 — 그때도 앞의 지식은 그대로 쓰인다.

무엇이 검증되었는가. 이 책이 지면에 인쇄한 범위는 좁고 분명하다. 이 부의 예제 29 개를 포함해 책의 예제 223 개 전부가 매 빌드마다 컴파일·실행되고, 그 출력이 지면에 그대로 실린다(GCC 기준, Clang 으로 교차 검증). 함께 실린 판은 vendor/proven/ 의 스냅샷 하나다. 곧 여기 실린 코드가 이 환경에서 돈다는 사실까지다.

아직 검증되지 않은 것. 그 밖은 검증되지 않았다. proven 은 거대한 프로젝트에 쓰여 본 적도, 여러 해 운영된 적도, 여러 독립 사용자를 거친 적도, 독립적인 보안 감사를 받은 적도 없다. API 도 ABI(application binary interface) 도 아직 약속하지 않는다. 「현대적」· 「안전」·「안정적」 같은 낱말이 이 부에 나온다면, 그것은 설계가 겨냥한 방향을 가리키는 말이지 성숙도를 증명하는 말이 아니다. 실무에 쓸지 판단할 자료는 99장에 표로 정리해 두었다 — 무엇이 확인됐고 무엇이 아직 아닌지, 그리고 무엇이 바뀔 수 있는지.

91.2 이름이 말하는 것 — 유래(provenance)#

이름은 미술 쪽 낱말에서 왔다. 프로버넌스(provenance)는 작품의 내력을 뜻한다 — 어디서 나와 누구를 거쳐 여기 왔는가. 내력을 못 대는 그림은 진품이어도 진품임을 증명하지 못한다.

C 의 기억 모형이 이 낱말을 거의 같은 뜻으로 쓴다는 것을 38장에서 이미 보았다. 포인터에는 주소만이 아니라 어떤 객체에서 유래했는가라는 보이지 않는 딱지가 붙어 있고, 최적화기는 그 딱지를 실재로 취급한다. 그래서 두 포인터가 비트까지 같은 주소를 담고도 서로 다른 것을 가리킬 수 있다.

이 이름을 택한 까닭은 라이브러리의 답이 바로 그 자리를 향하기 때문이다. 유래를 지키는 코드를 「조심해서」 쓰는 것은 사람이 안정적으로 해낼 수 있는 일이 아니다 — 규칙이 눈에 보이지 않고, 어긋난 결과는 최적화 수준을 올릴 때에야 나타난다. 그래서 날 포인터 산술을 좁은 자리 하나에 가두는 쪽을 택했다. 뷰는 포인터와 길이를 함께 지니고, 컨테이너는 제 범위를 안다. 그러면 「두 버퍼를 하나처럼 훑는다」 같은 문장을 실수로는 쓸 수 없게 된다.

91.3 무엇을 대신하려는가#

한 줄로 줄이면 이렇다 — 표준 라이브러리의 낡은 자리를 아래에서부터 갈아 끼우되, 표준 라이브러리를 몰아내지는 않는다.

이 책이 제11부에서 하나씩 짚은 함수들 — strcpy·strtok·sprintf· errno·qsort·rand·atoi — 은 저마다 크기를 모르거나, 숨은 상태를 지니거나, 실패를 값으로 주지 않는다. proven 은 그 각각에 대해 크기를 알고, 검사하고, 드러내는 짝을 하나씩 둔다.

그러나 libc 를 대신하는 물건은 아니다. 이 라이브러리는 당신의 main 을 갖고 싶어 하지 않는다.

한 모듈만 써도 되고 전부 써도 된다. 이미 링크하고 있는 것들 옆에 그대로 놓인다.

91.4 설계를 결정한 약속들#

이 부의 아홉 장이 하나씩 풀어 볼 것을 미리 목록으로 둔다. 각 줄이 곧 한 장의 주제다.

• 소유가 시그니처에 있다. 누가 할당하고 누가 돌려주는지가 인자 목록과 반환 타입에 적혀 있다(94장).
• 실패는 반환 타입에 있다. 실패할 수 있는 함수는 결과를 값으로 돌려주고, 중요한 것들은 [[nodiscard]] 라 무시하면 컴파일러가 막는다(92장).
• 자르지 않고 거부한다. 들어가지 않는 경로는 짧아진 경로가 아니라 오류다 — 70장의 strlcpy 논쟁이 바로 이 자리였다(95장).
• 실패해도 원자적이다. 문서가 그렇게 적은 자리에서는, 늘리기에 실패해도 원래 자료가 남는다(97장).
• 빌린 뷰는 소유하는 것과 다른 타입이다. 수명을 타입이 말한다(93장).
• 플랫폼은 한 겹에 모여 있다. 운영체제를 부르는 코드가 platform/ 밖으로 나가지 않아, 프리스탠딩 빌드에서 통째로 떨어져 나간다(99장).

91.5 무엇이 아닌가#

가지 않기로 한 자리를 먼저 적어 두는 편이 서로에게 낫다.

• libc 대체품이 아니다. 가비지 컬렉터도, 프레임워크도 아니다. 프로세스도 빌드 그래프도 오류 정책도 가져가지 않는다.
• 암호 라이브러리가 아니다. 해시(SHA-256 포함)와 OS 강도의 난수는 있지만, 서명·키 교환·비밀번호 해싱(KDF)·인증 암호화·TLS 는 일부러 없다.
• 플랫폼 층이 모든 것을 덮지 않는다. 기억·파일·시간·매핑·환경 변수·콘솔 입출력·스레드까지다. 프로세스 제어(fork·exec·파이프), 터미널 제어, 네트워크는 덮지 않는다 — 그 일이 본체인 프로그램은 POSIX 나 Win32 를 직접 부르게 되고, 「플랫폼 #ifdef 가 없다」는 성질도 거기까지는 가지 않는다.
• 메모리 안전 언어가 아니다. C 다. 계약을 어기면 어긴 대로 된다. 다만 어기기 어렵게, 어겼을 때 드러나게 만들어 두었을 뿐이다.

91.6 설치할 것이 없다는 선택#

proven에는 설치 절차가 없다. 받아 둔 소스를 프로그램과 함께 컴파일하면 그만이다. 소스는 이 책의 저장소 github.com/rubidus-api/proven_c_book 의 vendor/proven/ 에 함께 들어 있다. 중요한 디렉터리는 둘뿐이다.

• src/proven/ — 이식 가능한 본체. 여기서는 운영체제를 부르지 않는다.
• platform/ — 시스템 호출을 하는 얇은 층. 새 기계로 옮길 때 바꿔야 할 유일한 부분이다.

운영체제가 없는 환경(임베디드)에서는 platform/을 빼고 빌드한다. 이 분리가 라이브러리 전체의 모양을 결정했다 — “어디서나 돌아야 한다”는 요구가 곧 “숨은 할당도, 숨은 전역 상태도 두지 않는다”는 규율이 된다.

91.7 이 책의 예제는 어떻게 빌드되는가#

정직하게 밝혀 두면, 이 책의 proven 예제들은 다음과 같이 컴파일된다. 라이브러리 소스를 한 번 목적 파일로 만들어 두고, 예제와 함께 링크한다.

$ cc -std=c23 -O1 -Ivendor/proven/include -c vendor/proven/src/proven/*.c
$ cc -std=c23 -Wall -Wextra -Werror -Ivendor/proven/include \
     hello.c vendor-obj/*.o -lm -o hello

첫 줄이 본체를, 둘째 줄이 내 프로그램을 다룬다. -I는 헤더를 찾을 자리를 알려 주는 것(56장), -lm은 수학 함수를 잇는 것이다. 이 두 줄이 이 책의 검증 스크립트가 실제로 매번 돌리는 명령이고, 지면에 인쇄된 모든 실행 결과는 그렇게 만들어진 프로그램의 출력이다.

91.8 첫 프로그램#

#include <proven.h> 하나면 라이브러리 전체가 열린다.

#include <proven.h>

int main(void)
{
    const char *name = "world";
    int         count = 3;
    double      ratio = 0.75;
    bool        ready = true;
    char        grade = 'A';

    /* {} 는 자리표시자일 뿐 타입이 없다. 타입은 인자에서 온다 */
    proven_println("Hello, {}! You have {} messages.",
                   PROVEN_ARG(name), PROVEN_ARG(count));

    /* 어떤 타입이든 같은 자리표시자로 간다 */
    proven_println("ratio={} ready={} grade={}",
                   PROVEN_ARG(ratio), PROVEN_ARG(ready), PROVEN_ARG(grade));

    /* 서식 지정은 콜론 뒤에 붙인다 — 폭, 정렬, 자릿수 */
    proven_println("|{:>8}|{:<8}|{:.3}|",
                   PROVEN_ARG(name), PROVEN_ARG(name), PROVEN_ARG(ratio));
    return 0;
}

Hello, world! You have 3 messages.
ratio=0.750000 ready=true grade=A
|   world|world   |0.750|

한 줄씩 읽는다. proven_println은 서식과 인자를 받아 표준 출력에 한 줄을 찍는다 — 여기까지는 printf와 같다. 다른 것은 자리표시자다.

• {}에는 타입이 들어 있지 않다. %d도 %s도 아니고 그냥 {}다.
• 타입은 인자에서 온다. PROVEN_ARG(x)가 x의 타입을 보고 알맞은 꼬리표를 붙여 값을 감싼다.
• 그래서 90장의 셋째 버그 — 서식과 인자의 불일치 — 가 구조적으로 일어날 수 없다. 타입을 두 번 적지 않으니 어긋날 자리가 없다.

{:>8}처럼 콜론 뒤에 적는 것은 66장에서 본 폭·정렬·정밀도에 해당한다. >는 오른쪽 정렬, <는 왼쪽 정렬, .3은 소수 셋째 자리까지다. 정렬 기호가 앞에 오는 것이 printf와 다른 점이다.

91.9 세 가지 규칙 — 이 부 전체를 읽는 열쇠#

앞으로 만날 함수가 백 개를 넘지만, 시그니처를 읽는 규칙은 셋뿐이다. 이 셋만 손에 익히면 처음 보는 함수도 문서 없이 절반은 읽어 낼 수 있다.

1. 할당자를 인자로 받는 함수만 기억을 잡는다. 시그니처에 proven_allocator_t가 보이면 “이 함수는 할당할 수 있다”는 뜻이고, 없으면 한 바이트도 잡지 않는다. 그래서 임베디드에서 쓸 수 있는 함수와 아닌 함수가 눈으로 갈린다(94장).
2. 실패는 값으로 온다. 돌려줄 결과가 없으면 proven_err_t 하나를, 있으면 {err, value} 꾸러미를 돌려준다. err를 확인하기 전에는 value를 보지 않는다(92장).
3. 만든 것은 만들 때 준 할당자로 돌려준다. _create로 얻었으면 _destroy로 놓고, 이름에 view가 있으면 빌린 것이라 파괴하지 않는다(93–94장).

이름 규칙도 거의 예외가 없다.

91.10 객체 하나의 일생#

규칙을 말로 세 줄 읽는 것보다 실물 하나를 끝까지 따라가는 편이 빠르다. 다음 프로그램은 문자열 객체를 만들고, 쓰고, 돌려주기까지 전 과정을 한 화면에 담았다.

/* 첫 실전 프로그램 — 객체를 만들고, 쓰고, 돌려주는 전 과정.
   이 파일 하나에 proven 프로그램의 뼈대가 다 들어 있다. */
#include <proven.h>

/* ① 기억은 어디서 오는가 — 호출자가 정한다(할당자 매개변수).
   ② 실패는 값으로 온다 — err 를 확인하기 전에는 value 를 보지 않는다.
   ③ 만든 것은 만들 때 준 할당자로 돌려준다. */
static proven_err_t build_line(proven_allocator_t alloc,
                               proven_u8str_view_t who,
                               int count,
                               proven_u8str_t *out)
{
    /* 용량 64바이트짜리 문자열을 alloc 에서 얻는다 */
    proven_result_u8str_t made = proven_u8str_create(alloc, 64);
    if (!proven_is_ok(made.err))
        return made.err;

    proven_u8str_t line = made.value;      /* 확인 뒤에야 꺼낸다 */

    /* 서식으로 이어 붙인다. 실패하면 원본은 손대지 않은 채 남는다.
       형식화는 err 와 함께 "쓴 바이트/필요한 바이트"까지 돌려준다 */
    proven_fmt_result_t r = proven_u8str_append_fmt(&line, "{} has {} message(s)",
                                                    PROVEN_ARG(who), PROVEN_ARG(count));
    if (!proven_is_ok(r.err)) {
        proven_u8str_destroy(alloc, &line); /* 실패 경로에서도 반납한다 */
        return r.err;
    }

    *out = line;                            /* 소유권이 호출자에게 넘어간다 */
    return PROVEN_OK;
}

int main(void)
{
    /* 힙 할당자 — 표준 malloc 을 라이브러리 인터페이스로 감싼 것 */
    proven_allocator_t alloc = proven_heap_allocator();

    proven_u8str_t line;
    proven_err_t e = build_line(alloc, PROVEN_LIT("alice"), 3, &line);
    if (!proven_is_ok(e)) {
        proven_println("build failed: {}", PROVEN_ARG((int)e));
        return 1;
    }

    /* 소유 문자열 → 빌린 뷰. 뷰는 원본이 살아 있는 동안만 유효하다 */
    proven_u8str_view_t v = proven_u8str_as_view(&line);
    proven_println("line   = {}", PROVEN_ARG(v));
    proven_println("length = {} bytes", PROVEN_ARG(v.size));

    /* NUL 종단이 필요한 옛 API 와 만나는 자리 (복사·할당 없음) */
    proven_println("as C string = {}", PROVEN_ARG(proven_u8str_as_cstr(&line)));

    proven_u8str_destroy(alloc, &line);     /* 만들 때 준 그 할당자로 */

    /* 파괴는 구조체를 0으로 비운다 — 되돌린 버퍼를 다시 가리키지 않도록.
       그래서 파괴 뒤의 길이는 0이고, 이 객체는 더 쓰지 않는 것이 계약이다. */
    proven_println("after destroy, length = {}",
                   PROVEN_ARG(proven_u8str_as_view(&line).size));
    return 0;
}

line   = alice has 3 message(s)
length = 22 bytes
as C string = alice has 3 message(s)
after destroy, length = 0

여섯 자리를 짚는다.

① 할당자를 인자로 받았다. build_line의 첫 인자가 할당자라는 사실이 “이 함수는 기억을 잡을 수 있다”는 선언이다. 호출자가 힙을 줄지 아레나를 줄지 정한다(94장).

② 만들기는 꾸러미로 돌아온다. proven_u8str_create는 proven_result_u8str_t(즉 {err, value})를 준다. err를 확인하기 전에는 value를 꺼내지 않는다 — 이 순서가 92장의 전부다.

③ 용량은 “내용 기준”이다. create(alloc, 64)의 64는 담을 내용의 바이트 수이고, 라이브러리는 내부적으로 NUL 자리 한 바이트를 더 잡는다. 그래서 as_cstr이 복사 없이 C 문자열을 내줄 수 있다.

④ 실패 경로에서도 반납한다. 형식화가 실패하면 그때까지 잡은 문자열을 destroy로 되돌린 뒤 에러를 올린다. 이 패턴이 커지면 92장의 goto 정리 관용구가 된다.

⑤ 소유가 넘어가는 자리가 명시적이다. *out = line;이 그 자리다. 이 줄 뒤로 문자열의 주인은 호출자이고, 파괴할 책임도 호출자에게 있다.

⑥ 파괴는 구조체를 비운다. destroy 뒤 길이가 0으로 찍히는 것이 그 증거다. 되돌린 버퍼를 계속 가리키지 않게 하려는 것이며, 파괴한 객체는 다시 쓰지 않는다는 계약은 그대로다.

/* ① 확인 없이 value 꺼내기 */
proven_u8str_t s = proven_u8str_create(alloc, 64).value;   /* 실패면 쓰레기 */

/* ② 다른 할당자로 파괴하기 */
proven_u8str_destroy(other_alloc, &s);                     /* 계약 위반 */

/* ③ 뷰를 원본보다 오래 들고 있기 */
proven_u8str_view_t v = proven_u8str_as_view(&s);
proven_u8str_destroy(alloc, &s);
proven_println("{}", PROVEN_ARG(v));                       /* 죽은 자리를 읽는다 */

/* ④ PROVEN_ARG 를 빼먹기 */
proven_println("count={}", count);                         /* 컴파일되지 않는다 */

91.11 내 프로젝트에 붙이기 — 최소 Makefile#

앞의 두 줄을 매번 손으로 치지 않으려면 101장의 make를 쓴다. 라이브러리를 vendor/proven에 통째로 넣어 두었다고 할 때, 이 정도면 충분하다.

CC      = cc
CFLAGS  = -std=c23 -Wall -Wextra -Werror -O2 -Ivendor/proven/include
VSRC    = $(wildcard vendor/proven/src/proven/*.c) \
          $(wildcard vendor/proven/platform/*.c)
VOBJ    = $(VSRC:.c=.o)

app: app.o $(VOBJ)
  $(CC) $^ -lm -o $@

clean:
  rm -f app app.o $(VOBJ)

세 가지만 알아 두면 된다. -I 는 <proven.h>를 찾을 자리를 알려 준다 (56장). platform/ 은 운영체제를 부르는 얇은 층이라, 베어메탈로 갈 때는 이 줄만 빼면 된다(99장). -lm 은 실수 형식화가 쓰는 수학 함수를 잇는다 — 형식화에서 실수를 빼면(99장의 PROVEN_FMT_NO_FLOAT) 이것도 필요 없다.

첫 프로그램이 돌았다. 그런데 방금 쓴 proven_println도 사실은 실패할 수 있다 — 화면으로 가는 띠가 끊길 수 있기 때문이다(9장). 이 함수는 에러를 돌려주되 확인을 강요하지는 않는데, 그 선택 자체가 이 라이브러리의 에러 모델을 이해하는 좋은 입구다. 다음 장이 그것이다.