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

211–220 of 340 posts

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

#211

Post by lelanthran »

rswail wrote: post #208
lelanthran wrote: post #183

Earlier quoted context omitted.

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

Except that nearly all ISAs treat zero as a special value, with a Z-flag or equivalent for the last ALU result, and conditional branches around that result. PDP-11s, 68Ks, nearly all ISAs that I know about treat zero as special. It falls naturally out of the ALU operations. So why would people writing assembler code use another value unless they had to?

That's my point - they didn't, and used the zero as a sentinel when designing their HLL.

If, OTOH, the ISA had additional variants of those instructions that allowed usage of anything as a sentinel, HLL implementations of array would never have needed a fat pointer (length + memory).

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

#212

Post by flohofwoe »

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.

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

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

#213

Post by tremon »

layer8 wrote: post #171
mrlonglong wrote: post #2

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

There is a middle ground that Visual Basic (and then COM) took, with the BSTR type: It’s still a pointer to a zero-terminated char array, but there is a length field immediately preceding the first pointed-to byte. This is still compatible with a C string (assuming no embedded null characters), but BSTR-typed functions can take advantage of the length value.

> This is still compatible with a C string

Strictly speaking, it's not alignment compatible from CString to BSTR unless you declare all strings to be at most 255 characters or the cpu architecture doesn't require aligned access for multi-byte words (like x86). The BSTR alignment must match the alignment of the length word, meaning you can't convert a randomly-aligned C string to BSTR by simply attaching a prefix in-place.

Also, having the length embedded in the value rather than in the pointer makes it impossible to create BSTR (sub)slices without performing a memcpy. Fat pointers do not have this restriction.

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

#214

Post by Parodper »

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.

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

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

#215

Post by Parodper »

rswail wrote: post #160

Things that have bugged me for 40 years... * NUL terminated strings (and now, non UTF-8 encoded strings on input/output) * Using LF or CR or CRLF as line terminators, and pipe/comma-delimited fields when there were other unambiguous ASCII characters that could have been used (eg, GS, FS, RS) that would have made the encoding/decoding of line termination an I/O thing keeping HT/VT/CR/LF/FF as literally print related c…

LF makes the most sense, but they're all fine for text files. The issue is that CSV isn't text.

Last time I had to handle CSV files in bash, I converted them internally to RS and FS.

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

#216

Post by Ekaros »

Parodper wrote: post #215
rswail wrote: post #160

Things that have bugged me for 40 years... * NUL terminated strings (and now, non UTF-8 encoded strings on input/output) * Using LF or CR or CRLF as line terminators, and pipe/comma-delimited fields when there were other unambiguous ASCII characters that could have been used (eg, GS, FS, RS) that would have made the encoding/decoding of line termination an I/O thing keeping HT/VT/CR/LF/FF as literally print related c…

LF makes the most sense, but they're all fine for text files. The issue is that CSV isn't text. Last time I had to handle CSV files in bash, I converted them internally to RS and FS.

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.

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

#217

Post by GTP »

I always thought that srncpy was the safe alternative to strcpy. Now that I think of it, I'm unsure if the NUL terminator is counted into strncpy's size or not, which would be a likely source of errors. But, could someone explain better what the problems were? And also, would have to pick the right function in the list of given alternatives much better?

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

#218

Post by 1313ed01 »

tialaramex wrote: post #204
mirsadm wrote: post #146

Earlier quoted context omitted.

I'd be curious to see how much CPU time is wasted on looking for a null every time strlen is called. The extra length integer is probably insignificant compared to that.

It is very expensive if you repeatedly measure and forget the length, this is presumably some of the price in Google's problem where some engineers wanted to use 0-terminated char* as the type of a string but others wanted C++ std::string and so the software ends up measuring how long the string is, allocating and copying, then immediately forgetting that length, only to once again measure how long it is, allocate an…

The problem with C++ string slices is that after many years of C++ becoming increasingly memory-safe with std::string and smart pointers, now we reverted to something barely more safe than a C string.

I guess Rust can keep slices safe using some borrow checker magic or something, but C++ can't.

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

#219

Post by larodi »

fragmede wrote: post #7
larodi wrote: post #3

Wonder when is someone going to brave and fork the linux kernel and try to ffwd it with automatic programming.

why would you start there instead of creating something from scratch ?if you can port drivers just as easily meaning you don't especially give a shit about hardware you're running on in the first place, why even deal with linux? The battle tested LRU cache system?

Well in reality if you want a custom OS perhaps scavenging parts is a thing to do indeed. I just speculated whether Linux can be further improved by automatic programming and still keep the handmade parts.

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

#220

Post by larodi »

convolvatron wrote: post #14
fragmede wrote: post #7

Earlier quoted context omitted.

why would you start there instead of creating something from scratch ?if you can port drivers just as easily meaning you don't especially give a shit about hardware you're running on in the first place, why even deal with linux? The battle tested LRU cache system?

I've seen several workalike kernels in various stages of completion. at least one of them was able to run some pretty substantial applications (Postgres, nginx, that kind of thing), and that is still I guess around 250kloc. but it only really has drivers to support hypervisor devices. unfortunately as time goes by, the linux api surface gets larger and more convoluted. so there's going to be some coverage you're just…

Some if not most coverage will be off, indeed, but then the important stuff can get you lots of benefits. This makes sense even today for selectively patching the kernel. I’m sure many people been odd by the complexity of it while now it is doable albeit with agents…
Post reply on HN