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

Post by ekaryotic » Sun, Jun 21, 2026, 10:21 AM UTC

senfiaj wrote: post #45

none_to_remain wrote: post #41

Earlier quoted context omitted.

The size overhead of that is 2*sizeof(int) while the overhead of null termination is sizeof(char). If I remember the standard right, the former is worse by at least sizeof(char), and usually more in practice. This used to matter, sometimes still does.

Well, not saying to always use it, but if the string size is big enough, the overhead of 2 ints becomes relatively vanishing. For generic dynamically sized strings it probably has more advantages than disadvantages. But in any case, sure, if every single byte matters or some structure requires specific memory layout, then fine. I just don't think these things are the majority of use cases. Keep in mind that the cache…

Post by jll29 » Sun, Jun 21, 2026, 10:27 AM UTC

bc_programming wrote: post #151

jxbdbd wrote: post #138

Earlier quoted context omitted.

Why would a pascal string be any shorter than a C string? A C string is one pointer reaching all of memory, a Pascal string is two pointers reaching all of memory

A pascal string is a single byte with the length, followed by the data. Some implementations use more bytes for the length data, such as Delphi which changed over to a 4 byte prefix length, though those aren't technically Pascal strings anymore. I can't find anything about a Pascal string being two pointers?

  class IString { /* basic string functions */ };

  class MiniString : public IString {};
  class CZeroTerminatedString : public IString {};
  class PascalString : public IString {};
  class CppString : public IString {};

  use String = std::variant; // define one type for all impl.

Post by tialaramex » Sun, Jun 21, 2026, 10:30 AM UTC

nuc1e0n wrote: post #188

tialaramex wrote: post #119

Earlier quoted context omitted.

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

Post by imtringued » Sun, Jun 21, 2026, 10:31 AM UTC

lelanthran wrote: post #154

pdimitar wrote: post #65

Earlier quoted context omitted.

Sum types, of course.

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

Post by flohofwoe » Sun, Jun 21, 2026, 10:36 AM UTC

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…