7. Strings in C: buffers, ownership, and why gets() was removed

7.1 A "string" is a convention, not a type

#include <string.h>
#include <stdio.h>

int main(void) {
    char greeting[20] = "hello";   // 6 bytes used: 'h''e''l''l''o''\0', 14 unused
    printf("%zu %zu\n", strlen(greeting), sizeof(greeting)); // 5  20

    strcat(greeting, ", world");   // caller's job to ensure the buffer is big enough
    printf("%s\n", greeting);
    return 0;
}

strlen walks memory until it finds '\0' — there is no length prefix, no bounds. Every buffer-related CVE in C's history traces back to this one design decision, made in 1972 to save a byte per string on a PDP-11.

7.2 The functions to prefer, and why

#include <stdio.h>
#include <string.h>

int main(void) {
    char name[32];
    fgets(name, sizeof name, stdin);          // safe: stops at 31 chars + '\0'
    name[strcspn(name, "\n")] = '\0';         // fgets keeps the trailing newline — strip it

    char msg[64];
    snprintf(msg, sizeof msg, "hello, %s!", name);  // always bounded, always '\0'-terminated
    printf("%s\n", msg);
    return 0;
}

War story. strcpy/strcat/sprintf without bounds checking are exactly the family of functions behind decades of stack-buffer-overflow CVEs, starting with the 1988 Morris Worm (which exploited gets() in fingerd) through to modern IoT firmware CVEs today. -D_FORTIFY_SOURCE=2 (Section 30) adds runtime bounds checks to these calls when the compiler can determine buffer sizes, but the real fix is: default to the bounded variant by default.

7.3 C23: better ergonomics, same underlying model

C23 doesn't change the string model (still no built-in string type), but it removes friction: nullptr replaces the type-unsafe NULL macro, typeof lets you write generic string helpers without _Generic boilerplate, and [[nodiscard]] on a function like a custom safe_strdup forces callers to check the returned pointer for allocation failure.

// C23
#include <stdlib.h>
#include <string.h>

[[nodiscard]] char *safe_strdup(const char *s) {
    size_t n = strlen(s) + 1;
    char *copy = malloc(n);
    if (copy) memcpy(copy, s, n);
    return copy;
}

🔎 Checkpoint: strings and buffers

1. Predict what happens — will these two both "work," and if not, why does one look fine while quietly being wrong?

#include <string.h>
int main(void) {
    char buf6[6];
    strcpy(buf6, "hello");   // "hello" is 5 letters + '\0' = 6 bytes

    char buf5[5];
    strcpy(buf5, "hello");   // same source string, smaller destination
    return 0;
}

2. Spot the bug:

#include <stdio.h>
#include <string.h>
int main(void) {
    char line[256];
    fgets(line, sizeof line, stdin);
    if (strcmp(line, "quit") == 0) {
        printf("goodbye\n");
    }
    return 0;
}

The user types quit and presses enter, but "goodbye" never prints. Why?

3. Write it yourself: write void safe_concat(char *dst, size_t dst_cap, const char *a, const char *b) that writes a followed by b into dst, truncating safely if dst is too small — never overflowing, no matter how long a/b are.

#include <stdio.h>

void safe_concat(char *dst, size_t dst_cap, const char *a, const char *b) {
    snprintf(dst, dst_cap, "%s%s", a, b);   // snprintf always bounds to dst_cap, truncating cleanly
}

int main(void) {
    char buf[16];
    safe_concat(buf, sizeof buf, "hello, ", "world! this part gets truncated safely");
    printf("%s\n", buf);
    return 0;
}

4. Conceptual: why can't you use sizeof to get the length of a char * variable the way you can on a char[] array — and what's the one function that does give you that length?