Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux eliminates the strncpy API after six years of work, 360 patches

phoronix.com

Post reply on HN
Print view View original

101–110 of 340 posts

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#101

Post by ComputerGuru »

AnimalMuppet wrote: post #64
deathanatos wrote: post #57

Earlier quoted context omitted.

> See, AI was trained on existing data - on all that existing C code out there (sure, and also on all the papers and articles saying what was wrong with that C code). Those bugs are in the training data, and often not marked as bugs. So when AI generates C code, is it going to avoid making the mistakes that human code made? No, it's going to generate the kind of code it was trained on. How could it be otherwise? The…

It still could happen, if they had a way to judge the exceptional outputs from the mid and terrible ones. But I'm not sure they have that...

In far from an AI fanatic, but I would argue training it on GitHub PRs and general software patches already provides that. Instead of just seeing the static snapshot it sees “this code was replaced by this (hopefully better) code”

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#102

Post by qarl »

qustio wrote: post #97
qarl wrote: post #94

Earlier quoted context omitted.

Yes, I understand the difference in rigor. I refuse to believe the six year delay here was getting people to test a patch. Which, actually, Claude Code will also do quite well.

Not sure why you'd refuse to believe that when a single, simple patch in Linux can take months to make it into a kernel release. Here we're looking at 300 patches scattered throughout a kernel with millions of LoC. That's going to translate to a lot of mailing list back and forth even if every change was accepted on the first try without a fuss.

The lag there is not due to the review time. How many maintainers were involved? 300? Because I'm still finding it hard to understand how the work of 300 people handling 300 commits cannot be parallelized into months (per your own stat.)

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#103

Post by qustio »

qarl wrote: post #102
qustio wrote: post #97

Earlier quoted context omitted.

Not sure why you'd refuse to believe that when a single, simple patch in Linux can take months to make it into a kernel release. Here we're looking at 300 patches scattered throughout a kernel with millions of LoC. That's going to translate to a lot of mailing list back and forth even if every change was accepted on the first try without a fuss.

The lag there is not due to the review time. How many maintainers were involved? 300? Because I'm still finding it hard to understand how the work of 300 people handling 300 commits cannot be parallelized into months (per your own stat.)

To be clear my original statement was that the bottleneck was most likely not mechanical code changes (where CC would have the most direct speedup) but everything else involved in the process (testing, discussion/approval, inclination towards caution, deliberately narrowly scoped changes, etc).

Not that the Linux kernel approval procedures couldn't be streamlined, work couldn't be parallelized, or anything else like that, which would be a different discussion entirely.

You stated that Claude Code could have significantly sped up the process, so the burden of evidence here should be on how specifically these patches would have benefited/time saved from using LLMs. Hand wavingly saying "LLMs = faster" is too vague/broad of a claim without providing any evidence (and also unfalsifiable).

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#105

Post by maxlybbert »

senfiaj wrote: post #26

I wonder, why not use a string buffer paired with its length? For example, maybe use struct that has char pointer, and 2 ints (occupied length + total buffer length). Almost like c++'s std::string. This null terminator thing really sucks, it's potentially insecure and often unperformant.

It's definitely possible. And common, at least in some projects. The only real drawback is that sloppiness will lead to multiple slightly different nonstandard string types in the same project.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#106

Post by Animats »

qarl wrote: post #96
krupan wrote: post #93

Earlier quoted context omitted.

These stories with no details and no proof are not interesting or helpful.

My apologies. I did not want to be downvoted for promoting my own material. https://github.com/qarl/qscreensaver

A diff.[1]

[1] https://github.com/qarl/qscreensaver/commit/2843caba683495d5...

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#107

Post by DerSaidin »

strtomem_pad seems redundant with memcpy_and_pad, and also it requires the preprocessor: https://github.com/torvalds/linux/blob/1a3746ccbb0a97bed3c06...

I was curious: Why have it, instead of just using memcpy_and_pad?

AI's answer (paraphrased) was * Avoid possible bugs from manually write sizeof(dest) * Enforces the __nonstring Attribute * signals: "I am converting an actual C-string into a fixed-width legacy memory field." vs copy binary data & pad it.

Interesting to learn about the __nonstring attribute:

https://github.com/torvalds/linux/blob/1a3746ccbb0a97bed3c06... https://github.com/search?q=repo%3Atorvalds%2Flinux+__nonstr...

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#108

Post by qarl »

qustio wrote: post #103
qarl wrote: post #102

Earlier quoted context omitted.

The lag there is not due to the review time. How many maintainers were involved? 300? Because I'm still finding it hard to understand how the work of 300 people handling 300 commits cannot be parallelized into months (per your own stat.)

To be clear my original statement was that the bottleneck was most likely not mechanical code changes (where CC would have the most direct speedup) but everything else involved in the process (testing, discussion/approval, inclination towards caution, deliberately narrowly scoped changes, etc). Not that the Linux kernel approval procedures couldn't be streamlined, work couldn't be parallelized, or anything else like…

Right.

And what I'm saying is I refuse to believe the Linux kernel approval procedures are that inefficient. Therefore, your belief "bottleneck was most likely not mechanical code changes" is most likely incorrect.

It would be interesting to get the actual answer to this question.

EDIT: Substantially changing your argument after posting isn't nice. But to answer your charge - no - I never made that claim.

Re: Linux eliminates the strncpy API after six years of work, 360 patches

#110

Post by dpark »

D-Coder wrote: post #46

Note that "360 Patches" is 360 uses of strncpy that have been removed, not necessarily bugs.

I would imagine 360 patches removed way more than 360 uses of strncpy. But yeah, it’s not a given that each of these patches addressed a bug. (Also not a given that there were only 360 bugs fixed.)
Post reply on HN