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

Post by bobmcnamara » Sun, Jun 21, 2026, 3:22 PM UTC

flohofwoe wrote: post #212

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.

> Apple used CR Apple hasn't been using CR since the release of OSX (26 years ago). Microsoft could have made the switch at any time too (just as they could have switched to UTF-8 as universal text encoding on Windows), they just choose not to. In the end it's not the job of programming languages to clean up Microsoft's mess ;)

Post by bobmcnamara » Sun, Jun 21, 2026, 3:25 PM UTC

thiht wrote: post #229

> In place of strncpy, Linux kernel code should use strscpy() for NUL terminated destinations, strscpy_pad() for NUl-terminated destinations with zero-padding, strtomem_pad() for non-NUL-terminated fixed-width fields, memcpy_and_pad() for bounded copies with explicit padding, or memcpy() for known-length memory copies What a nightmare, does it have to be so convoluted?

Post by kps » Sun, Jun 21, 2026, 3:29 PM UTC

rswail wrote: post #209

flohofwoe wrote: post #199

Earlier quoted context omitted.

> non UTF-8 encoded strings on input/output UTF-8 on stdin/stdout works perfectly fine (unless you are on Windows of course, which is stuck in in the early 90s when it comes to international text encoding). > Using LF or CR or CRLF as line terminators This is also an operating system convention, and it would be better if programming languages wouldn't try to "guess" the correct line endings, since this causes more pr…

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.

Post by bigstrat2003 » Sun, Jun 21, 2026, 3:40 PM UTC

nuc1e0n wrote: post #185

twothreeone wrote: post #78

wow, very humbling. I'm actually amazed how many people contributed to this. It's easy to get attribution for "cool new features", but arguable removing bad features is even more important for something as fundamental as the kernel. Cudos! I'm sure these are the sorts of things that will go down as folklore from the "founding ages", when everyone will have forgotten how to understand source code in 50 years and the C…

I'm of the opinion AI slop code will become untenable way before that.

Post by bigstrat2003 » Sun, Jun 21, 2026, 3:44 PM UTC

BobbyTables2 wrote: post #111

mrlonglong wrote: post #2

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

Partly agree but there would have been squabbling on the data type of the size, unless it was variable length. The latter would have had other issues too. For a while, 16bit would probably have seemed too extravagant. Now 32bit would probably seem too small. For a “strongly typed” language, C is pretty damn loose where would have mattered.