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

91–100 of 340 posts

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

#91

Post by krupan »

CamperBob2 wrote: post #55
AnimalMuppet wrote: post #31

Earlier quoted context omitted.

AGI might. AI? No way. 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…

When's the last time you saw a decent coding model create a buffer-overflow bug while trying to use C strings? Serious question. Anyone else seen this happen in the last 12-18 months? If so, which model and version were you using?

How many people are writing C code with LLMs? I get the impression it's mostly JavaScript web apps

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

#92

Post by krupan »

qarl wrote: post #88
ninjin wrote: post #85

Earlier quoted context omitted.

> Of course I get downvoted for saying this. HN isn't interested in reality any more. I suspect that rather many of us are simply just tired of Claude and friends getting shoehorned into any conversation about programming at this point. It is about as fun as the Rust Brigade entering any discussion about C. It adds nothing new to the discussion and it is frankly tiring since we pretty much at any time have a handful…

Well - except in this conversation it's incredibly relevant. It took six years to do this work when the work is likely mostly mechanical and could have been done much more quickly and safely with an automated system. I thought automation would be interesting to HN - given the context and the fact it was not used.

An LLM is not a mechanical automated system. A deterministic search and replace would be a mechanical automated system. Clearly it wasn't that simple of a problem though.

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

#93

Post by krupan »

qarl wrote: post #71
Animats wrote: post #70

This is a job for Claude! What happens if you turn a job like that over to Claude Code? A mess? Good results? Code bloat? Worth trying on existing C programs.

I ran a test where I added a "light" mode to xscreensaver: unique changes to over 270 different C programs. It mostly did an amazing job in a short period of time. EDIT: Of course I get downvoted for saying this. HN isn't interested in reality any more.

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

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

#94

Post by qarl »

qustio wrote: post #89
qarl wrote: post #86

Earlier quoted context omitted.

It's a shame you're misrepresenting what is actually going on. In another comment here I explained that I have run a test: asking Claude Code to add a substantial feature to 270 different C programs. Despite your beliefs - it went extremely well.

Huh, are you confusing me with someone else? I don't doubt Claude Code did that, I do the same for refactors all the time. But xscreensaver theme tweaks for personal use have a much lower standard for quality control, regression testing, side effects, etc than a kernel used by billions of devices with thousands of interconnected drivers and subsystems. Not to mention the coordination problem to get every maintainer o…

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.

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

#95

Post by qarl »

krupan wrote: post #92
qarl wrote: post #88

Earlier quoted context omitted.

Well - except in this conversation it's incredibly relevant. It took six years to do this work when the work is likely mostly mechanical and could have been done much more quickly and safely with an automated system. I thought automation would be interesting to HN - given the context and the fact it was not used.

An LLM is not a mechanical automated system. A deterministic search and replace would be a mechanical automated system. Clearly it wasn't that simple of a problem though.

> An LLM is not a mechanical automated system.

Pretty sure that's exactly what LLMs in coding harnesses are.

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

#96

Post by qarl »

krupan wrote: post #93
qarl wrote: post #71

Earlier quoted context omitted.

I ran a test where I added a "light" mode to xscreensaver: unique changes to over 270 different C programs. It mostly did an amazing job in a short period of time. EDIT: Of course I get downvoted for saying this. HN isn't interested in reality any more.

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

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

#97

Post by qustio »

qarl wrote: post #94
qustio wrote: post #89

Earlier quoted context omitted.

Huh, are you confusing me with someone else? I don't doubt Claude Code did that, I do the same for refactors all the time. But xscreensaver theme tweaks for personal use have a much lower standard for quality control, regression testing, side effects, etc than a kernel used by billions of devices with thousands of interconnected drivers and subsystems. Not to mention the coordination problem to get every maintainer o…

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.

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

#98

Post by dare944 »

jibal wrote: post #75

The purpose of strncpy, which was originally part of the UNIX kernel code, was to copy file names to and from directory entries that consisted of a 2 byte inode number and a 14 byte zero-padded but not zero-terminated name field. I started warning my colleagues against using it the moment I saw it for the first time about 50 years ago.

strncpy appears somewhere around the Unix v7 time frame, however only as function in the standard C library. It is not used in the v7 kernel itself.

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

#99

Post by CamperBob2 »

krupan wrote: post #91
CamperBob2 wrote: post #55

Earlier quoted context omitted.

When's the last time you saw a decent coding model create a buffer-overflow bug while trying to use C strings? Serious question. Anyone else seen this happen in the last 12-18 months? If so, which model and version were you using?

How many people are writing C code with LLMs? I get the impression it's mostly JavaScript web apps

All the time. C, C++, occasionally some VHDL or Verilog.

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

#100

Post by ComputerGuru »

smackeyacky wrote: post #80
mrlonglong wrote: post #2

the zero terminated string is I think is computing's biggest mistake. Pascal style strings were much safer.

Zero terminated strings were the basis for an awful lot of useful software. Calling them the biggest mistake in computing is a bit OTT. I haven’t programmed anything Pascal related for 30+ years but I dimly remember thinking at the time that I wished the string system wasn’t so hard to use.

That argument isn’t valid. The argument would be “this string design enabled a whole lot of useful software” but that’s a different matter. (And it could very well be the case.)
Post reply on HN