alt Hacker NewsWhy not? The vulnerabilities you read about are due to oversights, not inherently lacking capabilities of the language. For every program exhibiting any given of such, you'll find thousands which don't make the same mistake at the same place. After all, most reported vulnerabilities are just a short patch away from being fixed.
Now human programmers might find it more difficult to get certain things right than others, but to a LLM only quantity of examples matters, no?
Replies
regularfry • today at 8:40 AM
It's more opportunities for a screw-up to lead to a vulnerability in ways the tooling won't catch by default, in a system where P(screw-up) > 0.
Out of curiosity, what is the largest C program you have written pre-LLM, and did you ever try to run it through valgrind*? The "oversights" in C tend to be extremely subtle and dangerous, and of a type that would be impossible to make in Go (or Rust or Common Lisp or whatever.) I do not have confidence in LLMs not falling victim to these subtleties at least once in a large application. I could be totally wrong! Perhaps they can all be found with a sufficient adversarial loops or something. I just have a really hard time imagining no problems of this sort occuring.
*(Memory leaks can probably be found by just having the LLM run valgrind itself and chase them down, but this gives you a good feel for the difficulties of writing safe C. Again, never tried any of this with LLMs myself, and I haven't written a nontrivial C program in years.)