strlcpy, or how CPUs defy common sense

With these two points in mind, today I'm just going to use a sized string (something like std::string_view C++) and convert them to nul-string only when required by an external API. This topic deserves a separate article, so I only mention it here tangentially.

But the good news is that outside of the C user base, which is heavily susceptible to the “default” bias (if something is the default, it's the right thing to do), the vast majority of developers have more or less realized that null-terminated strings were a mistake. This is obvious if you look at most other programming languages, including many new ones designed for systems programming: they don't use nul-strings by default (if they use them at all). Even languages ​​that inherit from C are moving away from using nul-strings — consider, for example, string_view from C++.

Conclusion

When discussing performance, it is important to be clear whether we are talking about it in a scientific sense or in a practical sense, because CPUs do not care about common sense and the Big O. Modern CPUs are incredibly complex and full of surprises. Therefore, the speed of an algorithm does not depend only on high-level algorithmic factors: we must also take into account low-level factors, such as cache misses, ILP, branch misprediction, and so on. Many things that may seem fast in common sense are slower in practice, and vice versa.