Live data from Hacker News

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

phoronix.com

281–290 of 340 posts

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

#281

Earlier quoted context omitted.

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.

Pascal had pointers? They could be `nil` too https://www.freepascal.org/docs-html/ref/refse15.html

The thread talked about sum types, which apparently appeared on ALGOL; although I don't know how much memory did an ALGOL compiler need.

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

#282
post #272

Earlier quoted context omitted.

Right. I am not claiming Claude Code creates perfect software. I am refuting your claim that using it would be cost prohibitive. I took the 10 most difficult patches from the git history - the ones that took the most back-and-forth to fix. I asked Claude to write them. Would you like to see the work? If you believe a human performs better at finding downstream effects - you need to prove that. I see no reason why it…

> If you believe a human performs better at finding downstream effects Once gain, you are not reading what is being said - no one made that claim! No claim was made in fact: it was a refutation. Specifically, the refutation is "this is why it took so many years".

> no one made that claim!

You did not literally make that claim but your cost argument hinges on it.

Without it, then Claude does about the same as a human and only costs $100.

Apparently I'm reading your comments more thoroughly than you are.

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

#283

Earlier quoted context omitted.

Would you even know? Serious question. The volume of code the models can produce, the subtle ways these bugs can manifest (or even only manifest when under attack), it seems like they would be easy to overlook.

I have a habit of getting GPT 5.5 to review everything Opus writes for me, and vice versa. The model in the reviewer role frequently finds things I overlooked myself. Occasionally in parts of the code I wrote. No modern LLM has found any buffer overflow bugs in parts of my code that originated from another LLM. Again, though, they have found one or two that were my fault.

Having one clanker verify the output of another has minimal, almost non-existent, persuasive value as evidence.

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

#284
post #216

Earlier quoted context omitted.

Line feed resetting position really makes no sense. It should just continue text from where the cursor was but on next line. Like staircase. You need CR to go back to start.

Yes, if you're talking to a terminal. But an in-disk file doesn't have a carriage to return.

Modern computer text output devices don’t have a “carriage” or a “feed” mechanism. I’d argue both CR and LF are legacy, anachronistic characters whose purpose was too device specific to make sense as a text encoding.

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

#285

Earlier quoted context omitted.

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

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

Apparently it's from 1901 (Murray code) or 1932 (ITA2).

The fact that both Apple's and CP/M codes came out roughly at the same time, both on microcomputers, shows that it was probably just a design decision.

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

#288
post #74

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

Almost as bad as newline-terminated lines. ;)

What's bas about them and what are the alternatives, genuinely curious since never seen them spoken of

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

#289

Earlier quoted context omitted.

> But we did get _Generic and VLAs! Party hard. VLA has been demoted to an optional feature in C11 (good). IMHO the current main problem is that the C stdlib is stuck in the K&R era and the stdlib APIs haven't even been updated to the language features added in C99 (e.g. make use of struct args and return values). A range struct (ptr/size pair) in the stdlib and new or updated string functions to use such ranges woul…

> IMHO the current main problem is that the C stdlib is stuck in the K&R era and the stdlib APIs haven't even been updated to the language features added in C99 (e.g. make use of struct args and return values). C++ has the same issue (only with more chaos and bloat). They add some new good idea (like optional) but don't update the rest of the standard library to make use of it. And they can't really, without breaking…

Someone tried to propose this in C++ a few years ago, but it never made it in. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p18...

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

#290

Earlier quoted context omitted.

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.

That's unnecessarily rude, and untrue in any case. Everyone has to learn stuff sometime, and most people won't naturally run into the implementation details of how higher level languages get translated into machine code.
Post reply on HN