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

241–250 of 340 posts

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

#241

Post by layer8 »

tremon wrote: post #213
layer8 wrote: post #171

Earlier quoted context omitted.

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

A BSTR object is compatible with functions expecting a C string. The other direction obviously never holds, unless the C string is a BSTR to start with.

Yes, there is a trade-off between slices using the same format and having compatibility with C strings. Hence “middle ground”.

You can still use a string-slice type on top of BSTR, it just would be a separate additional type. Note that languages like Java also don’t have a singular type for strings and string slices.

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

#242

Post by tialaramex »

1313ed01 wrote: post #218
tialaramex wrote: post #204

Earlier quoted context omitted.

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.

It's true that the borrowck is what checks you didn't screw this up in Rust, but "it's your job to never make mistakes" is just how C++ always works

If you keep const pointer to a std::string in C++ in 2016 that's exactly the same danger (of dangling pointers) as for a std::string_view in 2026, there's no change to that part.

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

#243

Post by senfiaj »

jerf wrote: post #52
chiph wrote: post #39

Earlier quoted context omitted.

Pascal did/does this, but eventually someone wants a string longer than the size portion can handle. Or wants the number of characters not the number of bytes.

I wasn't a programmer in these days, so I don't know if there's some other major concern that would kill this, but I sometimes wonder about whether we could have / should have used variable-length integers. That is, something like, 0-127 byte strings get their length prefixed, 128 - 16383 get two bytes of prefix, and the probably-rare 16384 - 2097151 strings would end up with three, though proportionally by that poin…

32-bit int isn't too much overhead. Just 3 additional bytes. I bet it's almost always better than c style strings. In the vast majority of situations the price isn't that bad, considering you make strings much more secure and potentially faster in string manipulations.

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

#244

Post by dare944 »

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…

> No other data structure works like this. You can't mess this up in an array, because no function that manipulates arrays is just going to keep going until there is a null.

This is patently false. Sentinel markers are used widely in array types. Consider GNU's getopt_long() function, a mainstay in GNU tools:

The argument longopts must be an array of [struct option] structures, one for each long option. Terminate the array with an element containing all zeros.

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

#245

Post by Parodper »

lelanthran wrote: post #202
imtringued wrote: post #198

Earlier quoted context omitted.

They don't need extra memory in Rust for the case of nullable pointers. The boring cases require an enum tag in C too. By bringing up the one thing that doesn't matter, your argument becomes purely ideological.

You're missing the point - give me a Rust compiler that can run and compile in 64KB memory, then you'll understand that the language C was constrained not just by what the output is running on, but by what the machines of the time could actually handle during compilation.

Borland's PASCAL did it on the IBM PC.

And which modern C compiler fits into 64KB? Even TCC needs 100KB. But that's beside the point. No machine of the last 36 (I'll push my chances, 40) years needs to fit a compiler in 64KB.

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

#246

Post by rurban »

GTP wrote: post #232
rurban wrote: post #225

Earlier quoted context omitted.

No, the safe alternatives end with _s. They do check matching buffer sizes, and enforce zero-termination. Unfortunately WG14 hates them also, because Microsoft. Microsoft did indeed break some of the, but you can use better alternatives, like my safeclib

> No, the safe alternatives end with _s. Could you please elaborate on this? Both `man strncpy_s` and `man strcpy_s` didn't return any manual page on my Linux system.

Search more. It's in safeclib and in the C standard

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

#247

Post by qarl »

lelanthran wrote: post #176
qarl wrote: post #86

Earlier quoted context omitted.

It's a shame you're misrepresenting what is actually going on. In another comment here I explained that I have run a test: asking Claude Code to add a substantial feature to 270 different C programs. Despite your beliefs - it went extremely well.

> In another comment here I explained that I have run a test: asking Claude Code to add a substantial feature to 270 different C programs. That's a different scenario, though. Would Claude have performed adequately if it had to add a specific feature to 270 programs buried in a set of 270m program, each of which may or may not have a dependency on one or more of the others, with virtually unbounded results to test? I…

[dead]

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

#248

Post by dare944 »

jibal wrote: post #158
JdeBP wrote: post #153

Earlier quoted context omitted.

In Unix Seventh Edition, ls and others read directory entries with fread() and parsed the struct direct themselves in application-mode code. The C library and application mode matter, here. On the gripping hand, there is no strncpy in the Spinellis 7th Edition source code; 4.2BSD was using strncpy() inside readdir() in 1982, though.

login used it, but not for directory entries: https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/cmd/lo... The code, but not the function, occurred in multiple places in the V6 kernel and userland.

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

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

#249

Post by RetroTechie »

dmazzoni wrote: post #104
mrlonglong wrote: post #2

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

255 characters ought to be enough for everybody, right?

You mean bytes.. we have multi-byte characters now.

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

#250

Post by qarl »

qustio wrote: post #84
qarl wrote: post #69

Am I going to be the first person to ask this after five hours? Really? Wouldn't this work be extremely easy to implement with an LLM coder?

I don't think the bottleneck was that it took six years to Ctrl-F strncpy and type in new code for each file.

[dead]
Post reply on HN