Hacker News Reader

Comment by chuckadams | Hacker News Reader

Both of them memory safety issues. C is just not fit for purpose in this decade.

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.

This is why languages like Rust have their place - their compilers impose the discipline and the restraint C doesn't. It's not impossible to write code with memory safety issues in Rust - it's just a lot harder. I remember saying the same about Java - it doesn't make writing the program any easier, but it makes writing some bugs difficult.

“C cannot fail; it can only be failed”

> C is not to blame for programmers using its features unwisely

"Make no mistakes" works about as well for humans as it does for AI, and we have decades of lived experiences to draw on for that verdict.

I didn't say "make no mistakes". I said "using its features unwisely". If you can't write software that manages shared mutable state, then don't do it. The world still needs lots of simpler programs.

Why can't simpler programs be written in languages that at least make an attempt to be memory-safe?

Of course you can. You should pick the right tool for the job.

There is a catch, however. Some languages will not allow you to take some shortcuts you know are safe unless you can prove them safe.

In this case the features are things like "allocating memory on the heap" and "incrementing a pointer."

It isn't like C has some "there be dragons" set of features that are hard to use. The source of exploitable memory safety issues is consistently just foundational language features.

And this isn't even a new thing for Programming. We already learned this lesson once.

Go look at a nineteenth century mechanical signal box. When you, through inattention or even malevolence, try to release signals so that train B can plough into train A, the lever won't move because it is physically impossible due to mechanical interlocking, you need to move a piece of sold metal through another piece of solid metal and it won't go.

Do not rely on humans to do boring but important things, they are very bad at this.

> 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.

> 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.

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.

That’s kind of my point. If your program is too complicated for you to be absolutely sure it’s correct and doesn’t misuse memory management or expose any way to misuse the system, then don’t. Write it with a different language.

Yes and no. I'd say there's nothing wrong with C - it's not evil - but maybe we still shouldn't use it because we should demand things C doesn't provide. There's nothing wrong with assembly code either but we rarely use it.

C was adequate for its era, though it had major problems from day one: like array pointer decay, lack of counted strings, aliasing just about anywhere and everywhere, and a legacy of squishy types it inherited from BCPL which was about as well-typed as Forth. Even so, it did yeomans work, but it's now long past its use-by date.

I still want C to burn in a fire, but I suppose it's at least earned an honorable Viking funeral (yeah I know that's ahistorical but you get the idea).

C allows you to express things easily which should not be easily expressable. When people do these things it is almost always in error.

That is the fault of the language.

"Writing secure C code requires discipline"

Ah the old, you're using the tool wrong.

Yes, perhaps, although a tool that no one seems to be able to use correctly, see kernel bugs, zero days everywhere, bugs in cURL by people who seem very rigorous and thorough, in google and microsoft products, etc. I'm not sure the tool is innocent in this. If the highest paid C developers in the world can't use it, who can?

What we have learned over the past many decades is that no amount of discipline solves this. It does not matter how world class your team is. Complex C programs that process untrusted input have security vulnerabilities.

Reply on news.ycombinator.com