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

331–340 of 340 posts

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

#331

Post by [deleted] »

atherton94027 wrote: post #309
pdimitar wrote: post #304

Earlier quoted context omitted.

Nobody claimed that "sum types are be all end all". I originally responded to "how would you handle cases where a value is unset without NULL" with "sum types" which are trivially presentable with bit masks if memory usage is of big concern (and nowadays in 99.9999% of the cases it genuinely is not). And, tagged unions are a thing and were a thing for a long time. Of course it's too late to change all this today; it…

Yeah and I was trying to explain that sum types don't work for pointers, without a significant performance hit. No one here is saying C is a great design, but in the context of 60 years ago, it worked out pretty well, and all the language which had additional runtime complexity (Pascal of course, but also Ada and FORTH) struggled because they didn't dial the right level of complexity

[deleted]

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

#332

Post by steveklabnik »

atherton94027 wrote: post #309
pdimitar wrote: post #304

Earlier quoted context omitted.

Nobody claimed that "sum types are be all end all". I originally responded to "how would you handle cases where a value is unset without NULL" with "sum types" which are trivially presentable with bit masks if memory usage is of big concern (and nowadays in 99.9999% of the cases it genuinely is not). And, tagged unions are a thing and were a thing for a long time. Of course it's too late to change all this today; it…

Yeah and I was trying to explain that sum types don't work for pointers, without a significant performance hit. No one here is saying C is a great design, but in the context of 60 years ago, it worked out pretty well, and all the language which had additional runtime complexity (Pascal of course, but also Ada and FORTH) struggled because they didn't dial the right level of complexity

[dead]

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

#333

Post by qarl2 »

krupan wrote: post #280
qarl wrote: post #95

Earlier quoted context omitted.

> An LLM is not a mechanical automated system. Pretty sure that's exactly what LLMs in coding harnesses are.

Still not deterministic

You understand that computer programs are deterministic unless someone explicitly injects non-determinism in them, right?

Even when they implement LLMs.

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

#334

Post by jibal »

jibal wrote: post #291
dare944 wrote: post #248

Earlier quoted context omitted.

> The code, but not the function, occurred in multiple places in the V6 kernel and userland. Yep. The code is essential given the design of the direct structure, which harkens back to the fixed-width data fields of punched cards.

It doesn't have anything to do with punch cards, it's to pack as many elements as possible into the very small amounts of memory on PDP-11s. A 16 byte directory structure (which divides evenly into a disk sector) with a 2 byte inode number and an up to 14 byte name is a memory-optimized structure, and memory optimization drove everything on UNIX. (I've been programming since 1965, used punch cards for a decade, was a…

I know the guy said "harkens", and I pointed out that it's wrong (but maybe he doesn't understand what it means, and thinks it's the same as "reminds me of"). Fixed size fields both precede and follow punch cards ... they are still used today in every struct.

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

#335

Post by qarl2 »

qarl2 wrote: post #333
krupan wrote: post #280

Earlier quoted context omitted.

Still not deterministic

You understand that computer programs are deterministic unless someone explicitly injects non-determinism in them, right? Even when they implement LLMs.

To the people downvoting me - I'm sorry, but it's true.

I know ChatGPT seems like it's non-deterministic - but that just a user preference.

The only real issue is if you have many people on the same server, the GPU contention can be non-deterministic in rare cases.

LLMs can be deterministic if you need them to be - it's just that most people prefer the human-like interface.

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

#336

Post by nuc1e0n »

tialaramex wrote: post #195
nuc1e0n wrote: post #188

Earlier quoted context omitted.

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

Are you muddling the Pascal strings with the string slice?

I mean nul terminated strings aren't great, but neither are strings with a defined length Strings generally have poor performance, so making them easy to use isn't necessarily a good thing.

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

#337

Post by DarkUranium »

astrobe_ wrote: post #147
DarkUranium wrote: post #114

Earlier quoted context omitted.

I like the D approach where arrays are just `struct { size_t length; T* ptr; }` internally --- and strings are just arrays of `immutable(char)`. It has a big advantage over the Pascal approach in that you can do zero-copy slicing, since the length is separate from the actual data. And `size_t` makes perfect sense for the length here. If your strings are longer than the address space (which `size_t` technically isn't,…

This only makes a difference in terms of memory size, not in terms of speed, because for decades processors and compilers have been optimized for moving bytes around. But one would note that in order to gain memory for this particular case of slicing, one introduces 2 extra words (size and pointer) for every other cases. Like perhaps the second most common string operation, concatenation. In those other cases, the be…

Yes, copying strings is definitely cheap, but allocating memory for the copy is absolutely not.

And I have my doubts w.r.t. 0-terminated strings being more efficient, with maybe the exception of some very specific niches.

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

#338

Post by rswail »

parineum wrote: post #294
flohofwoe wrote: post #212

Earlier quoted context omitted.

> 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 ;)

> In the end it's not the job of programming languages to clean up Microsoft's mess ;) Why is it Microsoft's fault? They just stayed on their legacy implementation, Linux and Apple chose to move from the legacy implementation to another legacy implementation. That seems dumb.

Both Linux and MacOS followed the Unix implementation, both of them are derivatives of Unix, so why would that change? Unix derived from Multics which chose LF.

The issue is that none of the print carriage movement ASCII characters should be used internally to indicate "end of line", because each of the chosen possibilities are used separately to indicate different carriage movements.

The logical decision would have been to choose one of the "separator" characters to indicate "separation of one line from another" and then allow the I/O drivers to decide what to send/receive to/from a particular device.

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

#339

Post by rswail »

codedokode wrote: post #323
rswail wrote: post #317

Earlier quoted context omitted.

Storing them as 32 bits wide in memory means you can at least index by a codepoint (if not a glyph).

I think you rarely need it. May I know what is your usecase that you need this often?

Extract the nth grapheme from a string of Unicode codepoints. Codepoints are 32-bit values.

Take into account that some Unicode codepoints work together to combine to form a grapheme which then links to a glyph for display.

If you use UTF-8 internally, you will be expanding out to full 32 bits when scanning the vector anyway.

So if memory isn't an issue (and most of the time it's not), indexing a vector by codepoint (ie 32 bits) makes more sense from a processing POV.

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

#340

Post by needusername »

skywal_l wrote: post #120
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…

Reminds me of Deepness in the Sky (Vernor Vinge) where a guy maintains a ship by doing software archeology. He is the only guy who knows what the Unix epoch is.

Doesn‘t he hack the ship and confuse the Unix epoch with the moon landing?
Post reply on HN