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

81–90 of 340 posts

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

#81

Post by smackeyacky »

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?

I had Claude write a bit of stupid C# the other day that had an off by one string truncate. Surprised the hell out of me.

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

#82

Post by AlotOfReading »

bellowsgulch wrote: post #22
dietr1ch wrote: post #9

Earlier quoted context omitted.

I think it was NULL itself. It was a long way until we realised we don't want invalid values and could use the type system to help us use special values safely.

Compared to scripting languages with actual tagged types, C doesn't really have a type system, and that's readily apparent to anyone who has written C in the last 43 years and debugged a program written in it. C pretends types exist with you, but once bytes hit the road, it's all real-life and segmentation faults.

C actually does have a type system and it's one of the bigger issues with the language. If it didn't, unaligned pointers and signed overflow would be totally fine.

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

#84

Post by qustio »

qarl wrote: post #69

Am I going to be the first person to ask this after five hours? Really? Wouldn't this work be extremely easy to implement with an LLM coder?

I don't think the bottleneck was that it took six years to Ctrl-F strncpy and type in new code for each file.

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

#85

Post by ninjin »

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.

> 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 of conversations on the front page already covering "AI" topics anyway (counting four at the time of writing this).

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

#86

Post by qarl »

qustio wrote: post #84
qarl wrote: post #69

Am I going to be the first person to ask this after five hours? Really? Wouldn't this work be extremely easy to implement with an LLM coder?

I don't think the bottleneck was that it took six years to Ctrl-F strncpy and type in new code for each file.

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.

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

#87

Post by asdfasgasdgasdg »

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 useful software would not have been less useful if the strings in it were represented as size + buf.

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

#88

Post by qarl »

ninjin wrote: post #85
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.

> 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.

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

#89

Post by qustio »

qarl wrote: post #86
qustio wrote: post #84

Earlier quoted context omitted.

I don't think the bottleneck was that it took six years to Ctrl-F strncpy and type in new code for each file.

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 on board and patches approved for each specific area when working on a project of that scale, even for a relatively narrow change.

Claude Code doesn't really help with that so don't see why the expectation would be a significant speed up (and doing it all in a single patch would definitely be rejected).

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

#90

Post by dare944 »

themafia wrote: post #10
mrlonglong wrote: post #2

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

> Pascal style strings were much safer. The limitations were brutal. Initially you could only have 255 bytes in a string. The length of a string and the size of the allocation are now separate and you may need to think about that unused memory in your design. The problem now doubles with the introduction of UTF-8. Your string size is in bytes and you need to track characters separately. If you want to create an array…

> You can spread propaganda and poorly sourced zeitgeist and be among friends but if you try to have a genuine conversation about programming languages you are made to be unwelcome immediately.

Indeed. And the ignorance of computing history in this discussion is particularly disturbing.

The context of this particular thread is "zero terminated string is ... computing's biggest mistake". This completely ignores the situation on the ground when C was developed. At the time, people were striving for a system programming language that sat above the level of assembly but was compact enough to run within the limited resources of the then emerging mini-computer systems. The PDP-11 on which C was developed was certainly not the first mini-computer, but it was among the earliest to have a regular enough instruction set and addressing model to make a general purpose, high-level system's language possible. These systems were extremely limited in memory; the PDP-11's instruction set is limited to directly addressing at most 64KiB (code and data) and many systems of the era were hardware limited to less than that. (Indeed, I regularly run an early version of Unix, including an early C compiler, on my PDP-11/05 which is maxed out at 56KiB [of actual core]). There was no way that even a brilliant engineer like Dennis Richie was going to be able to shoe-horn in "optional" types, or the mechanics of length-value strings into a compiler that has to run in such limited space, and produce code (e.g. the Unix kernel) that has to run in even less. The fact that strings and arrays are thin abstractions on top of pointers is both a brilliant compromise in design as well as a nod to then-prevalent assembly practice. It was the exactly kind of pragmatic decision that was needed to move computing along at the time. Of course the designs from this era are antiquated now. But they were not mistakes.

Post reply on HN