Love C, hate C: Web framework memory problems

AI‑assisted novice C and web security

• The showcased C web framework is widely seen as a clean‑looking but fragile learning project, not suitable for production, especially on the public internet.
• Commenters argue that “novice + LLM” in C produces code that appears tidy but hides many memory and lifetime bugs; expert review, fuzzing, and sanitizers are considered mandatory.
• Some note the irony that the same AI used to generate the code could have been used to audit it, if the author had asked better questions.
• There’s disagreement on whether hobby projects with serious bugs are acceptable to deploy: some see them as part of learning, others stress that anything internet‑facing now faces constant probing and must meet higher safety standards.

C vs Rust, Go, and other languages

• Several participants praise C’s simplicity and readability relative to modern C++/Rust, but acknowledge that “safe” C quickly becomes ugly and verbose.
• A long subthread debates Rust’s community, adoption barriers, tooling speed, and interop with C/C++; some were put off by early Rust evangelism, others see disproportionate backlash (“Rust derangement”) from C/C++ circles.
• There’s disagreement over how critical memory safety is versus other security issues, and whether Rust’s complexity is justified. Some see Rust (and similar tools) as ethical progress; others argue most real‑world risk still stems from logic bugs, configuration, and human factors.
• Go, Java, Zig, Nim, etc. are discussed as alternatives; many stress that C will remain entrenched for decades and that switching entire ecosystems has large “cost to change”.

C safety practices, integers, and tooling

• Experienced C programmers describe strategies: avoid open‑coded pointer arithmetic, encapsulate string operations, use opaque types, shrink scope, avoid globals, assert aggressively, and rely on sanitizers and fuzzers (e.g., libFuzzer, ASan/UBSan, valgrind).
• There’s detailed debate over signed vs unsigned lengths: some advocate signed sizes so sanitizers can trap overflow; others prefer unsigned with simple invariants. All agree that mixed signed/unsigned arithmetic is a subtle C footgun.
• Examples like char msg[static 1], atoi, and strcasecmp are cited as deceptively “safe” or convenient APIs that actually introduce UB, locale bugs, or uncheckable errors; strtol/strtonum‑style interfaces are preferred.

Allocation, parsing, and “good C code”

• Many frame “good C” as minimizing dynamic allocation and copying, using arenas or per‑thread pools, and doing in‑place parsing of protocols/JSON where possible. Others push back that zero‑alloc is not mandatory, and over‑optimizing early can hurt clarity and correctness.
• In‑place JSON/XML parsing with pointers into a read‑only or mutable buffer is discussed as feasible but tricky, especially around escaping and Unicode handling.
• Some argue that Java‑style OO abstractions and heavy builder/manager patterns map poorly to C, where manual memory tracking dominates design; others note you can adopt non‑idiomatic styles in any language, but doing so increases maintenance risk.

Learning, history, and pedagogy

• Several comments lament that software “reinvents itself” every generation, ignoring decades of prior languages (Modula‑2, Oberon, etc.) that solved many of these problems.
• There’s a side debate on LLMs, books, and interactive labs for learning: AI excels at producing examples, but books and foundational papers are seen as better for conveying core concepts and history.