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

121–130 of 340 posts

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

#121

Post by qarl »

qustio wrote: post #115
qarl wrote: post #108

Earlier quoted context omitted.

Right. And what I'm saying is I refuse to believe the Linux kernel approval procedures are that inefficient. Therefore, your belief "bottleneck was most likely not mechanical code changes" is most likely incorrect. It would be interesting to get the actual answer to this question. EDIT: Substantially changing your argument after posting isn't nice. But to answer your charge - no - I never made that claim.

Sorry, I didn't feel like this thread needed to be dragged out any longer since it's going in circles at this point and expanded my comment, but I didn't realize you had already replied.

Well - not really a circle. I keep saying the same thing over and over and you keep throwing arguments at it, unsuccessfully.

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

#122

Post by dietr1ch »

MBCook wrote: post #68
clnhlzmn wrote: post #62

Earlier quoted context omitted.

The way we do it in modern languages with things like std::optional and even that is not the best example.

And higher level languages that works. But what do you do when you get down to low level C or assembly? You basically end up with null/0 don’t you?

Eventually you end up with registers that probably allow for 2^N values. But the point is not thinking about the machine executing the instructions, but the construction on top of it that has a safer design.

Seeking performance we've been very prone to avoid abstractions and over and over again have shown why we need the safe abstractions.

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

#123

Post by atherton94027 »

pdimitar wrote: post #65
atherton94027 wrote: post #49

Earlier quoted context omitted.

Genuinely curious, how would you handle cases where a value is unset without NULL? This is a legitimate case that happens a lot in eg data modeling

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

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

#124

Post by smj-edison »

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 use Zig, which has slices, so so far none. But man, it can't get ref counting right to save its life. There have been remarkably few times it's gotten it right on the first try. My codebase considers OOM recoverable, so it keeps forgetting to clean up memory when OOM is raised. Even in the happy path though it still messes up ref counting. I use Kimi k2.6.

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

#125

Post by appplication »

lambdaone wrote: post #48

This sort of boring grind is where the real work of systems engineering is done. Big infrastructure projects like this work on making the Linux kernel more reliable while still keeping it workable throughout the process move on the scale of decades, not months.

On one hand I understand why it’s decade scale (the long tail of users/dependencies is really, really long) but on the other hand it doesn’t feel like a tenable pace at which we can make meaningful long term progress. Less of a gripe and I guess more a paradox of critical infrastructure.

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

#126

Post by mvdtnz »

lambdaone wrote: post #48

This sort of boring grind is where the real work of systems engineering is done. Big infrastructure projects like this work on making the Linux kernel more reliable while still keeping it workable throughout the process move on the scale of decades, not months.

[flagged]

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

#127

Post by paavohtl »

MBCook wrote: post #68
clnhlzmn wrote: post #62

Earlier quoted context omitted.

The way we do it in modern languages with things like std::optional and even that is not the best example.

And higher level languages that works. But what do you do when you get down to low level C or assembly? You basically end up with null/0 don’t you?

Rust is a significantly higher level language than C, but it can be used it almost all environments where C is used; provided there's a supported compiler target for it. In (safe) Rust, null is basically a guaranteed compiler optimization. Optional / nullable values are represented via Option, which is a sum type of Some(T) and None. When a reference or other pointer-like value (e.g. Box, an owned heap allocation) is wrapped in Option, the compiler can use the invalid bit patterns of T (such as null) to represent the None variant. This is called niche optimization.

So yes, it's nulls underneath, but the developer never has to think about them.

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

#128

Post by zeroonetwothree »

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.

C is not really strongly typed.

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

#129

Post by Gibbon1 »

AlotOfReading wrote: post #82
bellowsgulch wrote: post #22

Earlier quoted context omitted.

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.

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.

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

#130

Post by pjc50 »

msla wrote: post #15
mrlonglong wrote: post #2

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

In addition to having to pick a size for the length counter and then, later, having to differentiate between lengths in bytes, codepoints, and glyphs, you can't subdivide a Pascal string using pointer arithmetic. To pass just the end of a string into a function, you have to either copy the tail of one Pascal-style string to another with a smaller size value, or your string has to be a struct with an integer and a poi…

.. which is why you need a second type, the one dotnet calls "Span". A substring.
Post reply on HN