Hacker News Reader

Comment by jeffbee | Hacker News Reader

That is both really useful and a great example of why they should have stopped writing code in C decades ago. So many kernel bugs have arisen from people adding early returns without thinking about the cleanup functions, a problem that many other language platforms handle automatically on scope exit.

View on HN

You don't even need an LLM for this stuff. GCC has the __cleanup__ attribute, and kernel static analyzers like Smatch have been catching missing unlocks for a decade now. People just ignore linter warnings when submitting patches, so the language itself isn't really the issue. The LLM is basically just acting as a talking linter that can explain the error in plain English

Linux doesn't have any of: sufficient testing, sufficient static analysis, or sufficient pre-commit code review. Under those conditions, which I take as a given because it's their project and we can't just swap out the leaders with more tasteful leaders, adding this type of third-party review feedback strikes me as valuable. Perhaps, to your point, it would also be possible to simply run static analyzers on new proposed commits.

To be honest, during my ~10 years of experience, I haven't stumbled on any _project_ that has _sufficient_ amount of either testing, static analysis, and/or, where everyone who contributes gives a damn about linter/formatter warnings or errors.

Unless there is a CI that fails immediately when these checks fail, and it is not possible to bypass/override, then of course quality in the codebase improves significantly.

But that is very hard to give business results, in terms of ROI, 99.9% of the PMs will sweep these under the rug, because of unclear ROI.

Another remark I have to make is that, these things should be in a cloud/container (isolated environment) somewhere. Because I know several people who has their git commit aliased with no-precommit-hooks, because well, otherwise they complain that it is too slow. (Slowness is another issue that can be improved, but again, less visible ROI than just adding the command-line switch)

Must we do this on every thread about the Linux kernel?

The beatings will continue until morale improves

yeah but Linux is love, linux is life. if you really want to get the beatings going:

Rust > C and GNU/Linux should be Rust.

also vim > emacs

This ought to help with that. https://thephd.dev/c2y-the-defer-technical-specification-its...

> stopped writing code in C decades ago.

And what were they supposed to use in 2006? Free Pascal? Ada?

Someone suggested C++ and you should see the response from Linus

https://harmful.cat-v.org/software/c++/linus

Of course I specifically avoided invoking that language's name within the context of kernel programming in fear of summoning a Linus.

And he's so right. I didn't think like that back then, but new/delete (which have to be overloaded for kernel) behind allocators behind containers, vtables, =0, uninitialized members, unhandled ctor errors, template magic, "sometimes rvo", compiler hints, "sometimes reinterpret cast", 3rd party libraries, it would have been a disaster 20 years ago. Now he's being nice to Rust partially to spite that lang I love some more.

Reply on news.ycombinator.com