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

181–190 of 340 posts

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

#181

Post by lelanthran »

pdimitar wrote: post #177
lelanthran wrote: post #154

Earlier quoted context omitted.

How do you expect to use sum types in assembly? Remember where C came from and why it was designed the way it was.

I remember why C stayed what it is at least: elitism and gatekeeping. And YAGNI, repeated millions of times, of which only the first few were correct. You're telling me OCaml / Rust / Haskell compile to fairy pixie dust? Obviously their compilers figured it out and it works.

> I remember why C stayed what it is at least: elitism and gatekeeping.

If that was the goal, it failed horribly - the gatekeeping didn't work because the popularity exploded.

> You're telling me OCaml / Rust / Haskell compile to fairy pixie dust? Obviously their compilers figured it out and it works.

I said nothing of the sort.

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

#182

Post by imtringued »

tialaramex wrote: post #156
zeroonetwothree wrote: post #128

Earlier quoted context omitted.

C is not really strongly typed.

"Strongly typed but weakly checked" It turns out that the machine is much better at the sort of boring mechanical tasks where thoroughness counts and imagination doesn't and so languages which do more, and more, and more checking pay off very well. Rust's borrowck is the obvious first thought today but say WUFFS will check that you've proved certain key properties, WUFFS doesn't need to insert runtime bounds checks f…

This is something that has irritated me for a long time.

Bounds checks and sized arrays and strings are mechanically very easy to perform by a machine. These are highly automated tasks.

There are some extreme cases where they ruin performance, but in the vast majority of cases they don't matter.

If you look at the type of tasks that cannot be automated, if going from no to full automation required an efficiency loss of 5%, most people would see taking the hit as an obvious choice.

And this is where the problem becomes recursive. You can build a language where the runtime check becomes a compile time check.

We ought to abandon the C paradigm of shifting all the work to the developer and shift more work to the machine.

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

#183

Post by lelanthran »

rswail wrote: post #180
lelanthran wrote: post #167

Earlier quoted context omitted.

I am not sure what this is in response to. Can you explain which point of mine you are responding to?

> If the hardware had instructions for sentinel values, things would be easier (Like how DOS calls used '$' termination for strings) and safer. A zero is a sentinel value and is catered to by all ISAs. Why would using a "$" be any easier/safer than a NUL?

> A zero is a sentinel value and is catered to by all ISAs.

> Why would using a "$" be any easier/safer than a NUL?

I didn't say it had to be '$'; I specifically said that the sentinel would be loaded into a register. In that case it could be anything, including zero (for the snippet you posted), or INT_MAX if the code iterated across an array of integers, etc.

By having rep/mov variants that use sentinels, a lot of the HLL problems go away - Java, C#, Python, etc would all look very different today if the ISAs from the 80s included sentinal variant of memory instructions.

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

#185

Post by nuc1e0n »

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.

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

#186

Post by pjmlp »

rswail wrote: post #164
pjmlp wrote: post #142

Earlier quoted context omitted.

All those limitations were sorted out in 1978 with Modula-2 and open arrays, aka spans. What about the UNIX and C folks propaganda of C being the first systems language, or always focusing on the original Pascal used for teaching and not everything else that followed up with Mesa, Modula-2, Ada, Object Pascal and friends, none of them with said limitations.

C was specifically developed to allow Unix to be ported. It was a systems programming language and the first well known/successful one. There was BCPL and then B before that, which is why the language is called "C". Pascal was considered a teaching language, along with "Algorithms + Data Structures = Programs" by Wirth etc. The UCSD P-system was one of the first "IDEs" and used Pascal and a bytecode interpreter of th…

Successful systems languages trace back all the way to JOVIAL in 1958.

You missed quite a few between JOVIAL, and C being adopted outside Bell Labs.

Modula-2 was as widely available as C was outside UNIX and universities with access to UNIX source code.

It took a while for proper C to actually be "used for everything else", until the early 1990s actually, and by then anyone sensible would be much better with Typescript for C, aka C++.

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

#187

Post by pdimitar »

lelanthran wrote: post #181
pdimitar wrote: post #177

Earlier quoted context omitted.

I remember why C stayed what it is at least: elitism and gatekeeping. And YAGNI, repeated millions of times, of which only the first few were correct. You're telling me OCaml / Rust / Haskell compile to fairy pixie dust? Obviously their compilers figured it out and it works.

> I remember why C stayed what it is at least: elitism and gatekeeping. If that was the goal, it failed horribly - the gatekeeping didn't work because the popularity exploded. > You're telling me OCaml / Rust / Haskell compile to fairy pixie dust? Obviously their compilers figured it out and it works. I said nothing of the sort.

You asked how sum types work in assembly. I'm telling you that at least 3 compilers figured that part out.

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

#188

Post by nuc1e0n »

tialaramex wrote: post #119
cm2187 wrote: post #118

Earlier quoted context omitted.

Today yes, but 40 years ago someone made the decision that a string was a char array and that every string manipulation going forward would require manipulating arrays. Talking about costly decisions. It’s actually interesting to compare the pain and suffering of switching to a string datatype in the 80s (refactoring the limited code base then) vs the next 40 years of unnecessary boiler plate syntax and bugs for not…

Linux doesn't exist in the 1980s, Linus started this work in the 1990s. But yes, the string slice type should have existed in C89 and it's very obvious from here that not having something of this sort - maybe what Rust would call &[u8] the reference to a slice of bytes - was a big problem for C. The correct way to represent this is what's called a "fat pointer". A pair of values, one is a conventional "thin" pointer…

That's what pascal did back in the day, but 255 byte strings were all that was needed back then so only a byte was needed to store the length. Does that still sound maintainable? Anyhow, some developers put data into strings when they shouldn't, and require doing that in the APIs they publish. Strings, whether NUL terminated or with stored length, aren't always the best choice architecturally so making them easy to use isn't necessarily a good idea.

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

#189

Post by imtringued »

AlienRobot wrote: post #16
themafia wrote: post #10

Earlier quoted context omitted.

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

>The problem now doubles with the introduction of UTF-8. Your string size is in bytes and you need to track characters separately. That isn't really a problem. The problem with null-terminated strings is specifically what happens when you reach the end of the allocated array and there ISN'T a NULL character. Every string function is designed to keep going until it finds the NULL character, so if a hacker gets rid of…

If I zero out the destination buffer of a strcpy, and the string is longer than the destination buffer I will run into a buffer overflow problem despite every byte being a zero byte. The absence or presence of the zero byte doesn't seem to be the deciding factor.

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

#190

Post by imtringued »

jkrejcha wrote: post #35
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.

The problem here is that null kinda is consequential of intentional design of the type system itself. In this way, I do think that null was discovered, rather than invented. Remember, C is a kinda "portable assembler" so the constructs in it are based relatively closely to how low level data structures are mapped out in memory. This is, and continues to be, an incredibly useful feature that makes C and C structs imme…

>[3]: Yes, even Rust. Although some (again in my opinion) unfortunate design decisions made it so that C-Rust FFI isn't zero cost because of how it treats spans/slices

If Rust slices already make you sad, then the thing I'm cooking up will make you cry for days.

Post reply on HN