> C is not to blame for programmers using its features unwisely and, as a result, writing buggy code. Writing secure C code requires discipline, and, most likely, keeping yourself limited to a subset of the language.

It sure is to blame. Evidence shows you need wisdom, discipline, and an impossibly high bar of encyclopedic knowledge of every feature of C and all common libc's combined with an inhuman perfection of never once making a single typo, and a vast amount of tooling to analyze the code and find some of the bugs that made it through anyway.

The best, most trusted, most accomplished C programmers I could name still have a track record of writing vulnerabilities triggered by C footguns, not just garden variety logic bugs that could affect code written in any language. Can I write more diligent C code than the OpenBSD team? Than the Linux devs? Than Fabrice "I made everything" Bellard? Not a chance, but C has bitten each of them. Us mortals don't stand a chance.

▲

rbanffy 2 hours ago | parent [-]

> Us mortals don't stand a chance.

I'd say it's just a matter of moving in shorter steps, test incrementally, use extensive tooling to poke holes at your code, and develop those Linux/BSD/Fabrice skills. You might not be able to accomplish as much as these people did, but that's OK as well. The world still needs simpler programs.

	▲	kstrauser an hour ago \| parent [-]
		Why even bother, though? I have +- 8 hours a day to write code. I can spend 7.5 hours writing business logic and .5 hours getting the thing to compile (Rust/Python/Java/C#/whatever), or .5 hours writing business logic and 7.5 hours convincing myself I haven't added an RCE. I just don't see a valid use case for writing non-trivial C programs today. Maintaining existing programs, sure. That stuff isn't going away. Writing anything new in it today, though, seems like engineering malpractice.