Comment by lukeh
This is the fix. The bug commit was squashed. I don’t really know what I need to prove here, except that Claude Code helped identify an issue and fix it.
This is the fix. The bug commit was squashed. I don’t really know what I need to prove here, except that Claude Code helped identify an issue and fix it.
Context: I’m working on a series of patches to support MDIO-less configuration of mv88e6xxx switches. They have not been submitted to netdev yet as they’re dependent on other unsubmitted patches from another kernel developer. The code above is a WIP so fixes have been squashed. You’ll have to take my word that I found Claude Code helpful in reviewing the code, I’m not going to dig around for the previous commit hash to satisfy some HN comment.
To the point of compilers warning about uninitialized variables, this surprised me; perhaps I was building without optimization.
You don’t have to prove anything.
If the LLM helps you, that is what matters to you. If it doesn’t help them, that is what matters to them. The problem is always the people trying to be “right”. If a person, project or company doesn’t want to allow/use LLMs for their controlled code, go ham, doesn’t bother me any. Why the reverse of that isn’t also true is baffling, but often par for the course here.
Compilers have been warning about unitialized variables for a very long time now. The claim was that the compiler missed that in a patch you reviewed for the kernel. The link posted does not show the review discussion nor a commit log showing that incremental fix, and so does not at all support the claim.