In a way this is strange because there us a huuuge new area of vulnerabilities caused by LLMs writing code that DWARFS the read/write out of array bounds issues C has.

▲

cue_the_strings 4 days ago | parent | next [-]

I agree.

But on the other hand, let's not kid ourselves, array out of bounds, use after free, resource leaks and bad type system, all of this isn't even close to an exhaustive list of C downsides. Beyond its direct limitations, C inspires an approach that is vastly inferior even if you follow all the best practices. Even compared to (modern) C++ it's much worse. I say this and I kind of like C.

If the approaches described in the article save us 30% of the effort of translating C codebases to Rust, it's still worth trying; we're unfortunately not very close to complete automation, but that's something worthy of pursuit.

▲

tmountain 4 days ago | parent | prev | next [-]

I understand the issues related to LLM leaking and re-distributing "private" information, but I'm curious which category of concerns you're referring to. Would you mind giving some context (genuinely curious) ?

	▲	jurschreuder 2 days ago \| parent [-]
		You can look at the vulnerabilities found graph of github. It stays about the same for years and then skyrockets up at around the time LLMs were invented. And they are all pretty simple vulnerabilities, exploitable even to people knowing nothing about how to get root access from a binary that has an out of bounds condition somewhere in randomly shuffled memory layout in a specific version if a C program.

▲

pornel 4 days ago | parent | prev [-]

The code needs to pass integrity checks of the safe Rust subset, which is a different challenge than writing dangerous code without feedback.