43 Safe input — blocking overflow, handling failure

43.1 Dissecting the accident — the epidemic called the boundary violation

Combine chapter 38′s boundary rule with chapter 42′s NUL termination and the most expensive accident pattern in C’s history assembles itself. Input longer than the container overwrites neighbouring memory (a boundary violation) — and if what was overwritten happens to be the return ledger of a function call (whose identity we see in the next chapter), an attacker seizes the program’s flow of execution with input alone. That is the substance of the buffer overflow attack, an epidemic running unbroken from the Morris worm (1988, chapter 42) to today’s security advisories. The statistics are lopsided too — in the major security bodies’ lists of “most dangerous software weaknesses”, the boundary-violation family has been a fixture at the top for decades.

Because C decided not to check bounds at run time (chapter 38), the defence has to be built in layers — functions that take a size (fgets), warnings and sanitizers (chapter 17), and the discipline of the parsing code itself. That last layer is this chapter’s subject.

43.2 How do the standard tools report failure

First, gather how the tools already in hand announce a failure. That they are all different is itself this chapter’s starting point.

The strtol family has the soundest contract of these, but using it correctly means checking three things at once — which is why practice does not call it directly but wraps it. That wrapping is this chapter’s five disciplines.

43.3 Five disciplines for handling a failed parse

/* 입력 해석의 실패를 다루는 다섯 규율 — 표준 C 만으로. */
#include <errno.h>
#include <inttypes.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* 실패를 '값'으로 돌려주는 결과 꾸러미.
   성공 여부와 값을 갈라 담고, 어디까지 읽었는지도 함께 돌려준다. */
struct parse_i64 {
    bool        ok;
    long long   value;
    const char *rest;      /* 해석이 멈춘 자리 — 이어 읽거나 오류를 가리킬 때 */
    const char *why;       /* 실패한 이유(사람이 읽는 말) */
};

/* [[nodiscard]] 는 "이 반환값을 버리면 경고하라"는 C23 의 표기다.
   실패 확인을 잊는 실수를 컴파일러가 잡아 준다. */
[[nodiscard]]
static struct parse_i64 parse_int(const char *text)
{
    struct parse_i64 r = { .ok = false, .value = 0, .rest = text, .why = "" };
    if (!text) { r.why = "empty input"; return r; }

    errno = 0;
    char *end = nullptr;
    long long v = strtoll(text, &end, 10);

    if (end == text)                 { r.why = "does not start with a number";  return r; }
    if (errno == ERANGE)             { r.why = "does not fit in this type"; r.rest = end; return r; }

    r.ok = true; r.value = v; r.rest = end; r.why = "";
    return r;
}

static void show(const char *text)
{
    struct parse_i64 r = parse_int(text);
    if (r.ok)
        printf("  %-24s -> ok: %lld, input left: \"%s\"\n",
               text, r.value, r.rest);
    else
        printf("  %-24s -> failed: %s\n", text, r.why);
}

/* 잘림을 오류로 다루는 복사 — "잘렸지만 성공"을 남기지 않는다 */
[[nodiscard]]
static bool copy_line(char *dst, size_t cap, const char *src)
{
    size_t n = strlen(src);
    if (n + 1 > cap) return false;          /* 잘릴 상황이면 아예 실패로 */
    memcpy(dst, src, n + 1);
    return true;
}

int main(void)
{
    puts("[1: return the failure as a value - success and value kept apart]");
    show("42");
    show("  42 and then some");
    show("forty-two");
    show("999999999999999999999999");

    puts("\n[2: say how far you read]");
    const char *csv = "10,20,30";
    long long sum = 0;
    const char *p = csv;
    for (;;) {
        struct parse_i64 r = parse_int(p);
        if (!r.ok) break;
        sum += r.value;
        p = r.rest;
        if (*p == ',') p++;
        else break;
    }
    printf("  sum of \"%s\" = %lld  <- rest lets you keep reading\n", csv, sum);

    puts("\n[3: truncation does not count as success]");
    char small[8];
    printf("  \"hello\" → %s\n",
           copy_line(small, sizeof small, "hello") ? "ok" : "failed (truncated)");
    printf("  \"hello, world\" → %s\n",
           copy_line(small, sizeof small, "hello, world") ? "ok" : "failed (truncated)");

    puts("\n[4: on failure, leave the output argument alone]");
    long long keep = -1;
    struct parse_i64 bad = parse_int("not a number");
    if (bad.ok) keep = bad.value;
    printf("  is the original value still there after the failure: %s (keep = %lld)\n",
           keep == -1 ? "yes" : "no", keep);

    puts("\n[5: let the compiler speak when you forget to check]");
    puts("  parse_int and copy_line are marked [[nodiscard]].");
    puts("  dropping the return value warns - that stops you forgetting to check for failure.");
    return 0;
}

[1: return the failure as a value - success and value kept apart]
  42                       -> ok: 42, input left: ""
    42 and then some       -> ok: 42, input left: " and then some"
  forty-two                -> failed: does not start with a number
  999999999999999999999999 -> failed: does not fit in this type

[2: say how far you read]
  sum of "10,20,30" = 60  <- rest lets you keep reading

[3: truncation does not count as success]
  "hello" → ok
  "hello, world" → failed (truncated)

[4: on failure, leave the output argument alone]
  is the original value still there after the failure: yes (keep = -1)

[5: let the compiler speak when you forget to check]
  parse_int and copy_line are marked [[nodiscard]].
  dropping the return value warns - that stops you forgetting to check for failure.

The listing’s parse_int puts all five into one function. One at a time.

43.3.1 1. Return failure as a value

Return “did it succeed” and “what is the value” kept apart. Return only a value, as atoi does, and there is no room to express failure; report a count, as scanf does, and what failed is not preserved.

struct parse_i64 { bool ok; long long value; const char *rest; const char *why; };

Returning a struct by value may look costly, but a struct this size usually rides in a couple of registers (chapter 47). Writing failure into the type is worth far more than that.

43.3.2 2. Let the compiler speak when a check is forgotten

Attach C23′s [[nodiscard]] and code that throws the return value away gets a warning.

[[nodiscard]] static struct parse_i64 parse_int(const char *text);

This moves “you must check” out of the documentation and into the compiler’s job. A rule a person has to remember is eventually forgotten, and the place it is forgotten is exactly the place the accident happens.

43.3.3 3. Say how far it read

strtol’s endptr is the good precedent. Return where parsing stopped as well and two things become possible — carrying on (the listing’s 10,20,30 sum), and pointing a person at where it went wrong (“it stopped at the third character”).

43.3.4 4. Do not count truncation as success

This is the most frequently broken discipline. Return “it did not fit, so I cut it to size” as a success and what follows is looking up a file under a truncated name and connecting to a truncated address.

The listing’s copy_line does nothing and returns failure when the text will not fit. That is the lesson of the long-standing problem of strncpy not reporting truncation (chapter 64).

43.3.5 5. On failure, touch no output

If a half-filled value is left in the result on failure, code will end up using it. Make change nothing on failure the contract and write it in the documentation — the last part of the listing checks exactly that.

43.4 Casting the discipline into a component

Build the same discipline by hand in every function and something is eventually left out. So practice’s next step is to cast the discipline into a component — one where failure surfaces as a value, bounds are always checked, and the compiler speaks up when a check is forgotten.

We have safe input. But a phrase went past in this chapter without explanation — “the return ledger of a function call”. Where in memory does what live, and when is it born and when does it die? The next chapter is that answer — lifetime and storage duration.