I've spent a lot of time digging around in other people's C code over the years, and with very few exceptions, the kind of low-level byte munging in the original post tends to be absolutely riddled with bugs. There are off-by-one errors, buffer overflows, integer overflows, and memory leaks. The error-handling code paths tend to be broken, too.
And if you run a fuzzer like libfuzz or American Fuzzy Lop, it will almost always find even more vulnerabilities. (A handful of C programs do better, including djb's tools, SQLite, dovecot, and significant portions of Apache. Apache seems to mostly succeed because it has good abstractions for strings and buffers.)
Back in 2002, I published a ~7,000 line XML-RPC library in C, with extensive unit tests. I ran it through multiple code quality tools, including Electric Fence. I spent a long time carefully examining each function for correctness. I chose Expat as my XML parser, because it was one of the best-written at the time.
Overall, I thought I was an unusually paranoid and careful C programmer. But here's the list of CVEs against my library and—most importantly—its dependencies: https://people.canonical.com/~ubuntu-security/cve/pkg/xmlrpc...
If anybody here writes C code, and if your code runs on potentially hostile data, I strongly recommend experimenting with a fuzzer. It can be a brutally humbling experience, even if you think you're an exceptionally careful programmer. And if you rely on anybody else's code, like I did, you inherit all their bugs.