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

261–270 of 340 posts

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

#261

Post by badsectoracula »

t-3 wrote: post #233
Conscat wrote: post #149

Earlier quoted context omitted.

A Pascal string has a leading length byte. Because that is one byte, the text can't exceed 255 characters.

For modern hardware, a 64-bit length is more practical though - no alignment issues. It seems to me that Pascal's specifying a single byte prefix was a language design "mistake" of the same type as NULL termination, putting hardware considerations into the language definition. Very practical for machines of the time, but not necessarily the best choice in hindsight.

The original Pascal didn't had a string type, that was introduced by various dialects.

FWIW all Pascal dialects since the 90s have a string type that allows more than 255 bytes. In Free Pascal strings are pointers to the first character with a header in a negative offset indicating the length, reference count and codepage (these fields are aligned depending on the CPU). For C compatibility the string is also null terminated so you can pass such a string to a C function and it'll work as expected. AFAIK Delphi also does the same.

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

#262

Post by imtringued »

atherton94027 wrote: post #123
pdimitar wrote: post #65

Earlier quoted context omitted.

Sum types, of course.

How are you going to build sum types in a way where you can interact with assembly or machine code? The CPU doesn't know about that stuff

Sum types map down to reading a tag and doing a comparison against fixed values.

I don't know what to tell you, but you're clearly not cut out to be a software developer in either machine code, assembly or C or any other language if you don't understand something this basic.

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

#263

Post by qarl2 »

lelanthran wrote: post #176
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.

> 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. That's a different scenario, though. Would Claude have performed adequately if it had to add a specific feature to 270 programs buried in a set of 270m program, each of which may or may not have a dependency on one or more of the others, with virtually unbounded results to test? I…

HackerNews is now censoring my replies. I did the math - all of these patches would have cost around $100.

Let's see if they'll let this account through.

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

#264

Post by qarl2 »

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.

I looked at the git history. The first three years were wasted waiting for a human to pick it up. He then very slowly submitted patches over 2 years.

Claude Code doesn't need to be interested to work.

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

#265

Post by bobmcnamara »

ptx wrote: post #234
EvanAnderson wrote: post #206

Earlier quoted context omitted.

I did a project to translate data framed in the ASCII field/record separator characters and it was gloriously easy. All the ugly escaping considerations with comma-delimited data went away and it became much easier.

What happens when the data contains the record or field separator characters? I suppose you could document that it's unsupported, and just drop or reject such values, but then the system couldn't be used to handle test data for such systems, for example.

Easy - don't

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

#266

Post by lelanthran »

qarl2 wrote: post #263
lelanthran wrote: post #176

Earlier quoted context omitted.

> 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. That's a different scenario, though. Would Claude have performed adequately if it had to add a specific feature to 270 programs buried in a set of 270m program, each of which may or may not have a dependency on one or more of the others, with virtually unbounded results to test? I…

HackerNews is now censoring my replies. I did the math - all of these patches would have cost around $100. Let's see if they'll let this account through.

It's like you are not even reading what is being said to you. You can't find the downstream effects using grep!

You can find the "strncpy"s with grep, but you cannot find all the downstream effect of those changes, especially if something downstream is relying on the broken behaviour!

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

#267

Post by gbin »

david-gpu wrote: post #222
anal_reactor wrote: post #192

Earlier quoted context omitted.

> but to be fair to them we didn't have the consensus we have today on the topic. This is my pet peeve of teamwork. We can choose solutions A, B or C. Each has upsides and downsides. We debate for two weeks, then we choose nothing.

Isn't that due to a lack of leadership, rather than a problem with teamwork itself? Somebody has to be ultimately in charge and willing to put a stop to endless debate.

It is more like a "design by committee" issue to me. The decisional structure needs to be built for some opinionated decision. When you have a committee there is not one clear thing they are solving for as everyone has an agenda to tug the language towards their own interests. The result of that can certainly be inaction because it is easier to say no than yes.

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

#268

Post by bobmcnamara »

Parodper wrote: post #214
rswail wrote: post #209

Earlier quoted context omitted.

No, it was an Apple, Unix, and Microsoft problem. Unix used LF, Apple used CR, Microsoft used CRLF. They are all ASCII carriage movement codes, which is about driving the paper feed and print head of an ASR-33 or equivalent. So they all made the "wrong" decision about what to store in a file. They just chose different wrong characters.

UNIX's LF precedes them by at least half a decade, probably more.

CRLR is Baudot, predating UNIX by what, a century ?

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

#269

Post by imtringued »

Gibbon1 wrote: post #129
AlotOfReading wrote: post #82

Earlier quoted context omitted.

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.

Problems with unaligned pointers are basically a hardware defect. Signed overflow is an issue because academics are unhappy computers only can do finite math. Issue with types and C is while the compiler knows about them the standards committees don't want you to be able to. If C had first class types more people would abandon C++ and that can't be allowed to happen.

The concept of alignment isn't a hardware defect, maybe limitation, but the reason why alignment is a thing has to do with the fact that in chip interconnects transfer blocks. You cannot perform misaligned memory accesses against RAM.

A similar limitation exists when peforming accesses against the cache, but at a much finer granularity.

For bytes, the alignment restriction obviously exists in the 8 bit level. You have one output byte and 64 multiplexer inputs.

If you scale this up to 8 bytes, you will need a lot of 64 Input multiplexers.

But even if you can take the silicon area hit, there is the problem of crossing cache lines and pages.

In the end, you cannot divide memory into blocks and allow primitives to cross those blocks without requesting both blocks at the same time. That's an inefficient waste of resources so why support the wasteful usecase in the first place?

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

#270

Post by lelanthran »

Parodper wrote: post #245
lelanthran wrote: post #202

Earlier quoted context omitted.

You're missing the point - give me a Rust compiler that can run and compile in 64KB memory, then you'll understand that the language C was constrained not just by what the output is running on, but by what the machines of the time could actually handle during compilation.

Borland's PASCAL did it on the IBM PC. And which modern C compiler fits into 64KB? Even TCC needs 100KB. But that's beside the point. No machine of the last 36 (I'll push my chances, 40) years needs to fit a compiler in 64KB.

> Borland's PASCAL did it on the IBM PC.

That's famously a single-pass compiler. Rust is famously unable to compile in a single pass.

It is not possible to make a borrow-checking language that compiles in a single pass.

> No machine of the last 36 (I'll push my chances, 40) years needs to fit a compiler in 64KB.

Exactly - that's why C is what it is: it wasn't a mistake, they were working under the constraints of the time. My original comment (that you appeared to disagree with) said specifically "Remember where C came from and why it was designed the way it was."

Let me ELI5 it for you: It was specifically designed to emit assembly in a single pass because of the constraints of the time.

WTF does "Hur Dur Rust Goodest!" comments mean in this context?

Post reply on HN