It's worth noting that strcpy() isn't just bad from a security perspective, on any CPU that's not completely ancient it's bad from a performance perspective as well.

Take the best case scenario, copying a string where the precise length is unknown but we know it will always fit in, say, 64 bytes.

In earlier days, I would always have used strcpy() for this task, avoiding the "wasteful" extra copies memcpy() would make. It felt efficient, after all you only replace a i < len check with buf[i] != null inside your loop right?

But of course it doesn't actually work that way, copying one byte at a time is inefficient so instead we copy as many as possible at once, which is easy to do with just a length check but not so easy if you need to find the null byte. And on top of that you're asking the CPU to predict a branch that depends completely on input data.

▲

amelius 20 hours ago | parent | next [-]

We should just move away from null-terminated strings, where we can, as fast as we can.

▲

masklinn 19 hours ago | parent | next [-]

We have. C is basically the only langage in any sort of widespread use where terminated strings are a thing.

Which of course causes issues when languages with more proper strings interact with C but there you go.

▲

saghm 14 hours ago | parent | next [-]

Given that the C ABI is basically the standard for how arbitrary languages interact, I wouldn't characterize all of the headaches this can cause as just when other languages interact with C; arguably it can come up when any two languages interact at all, even if neither are C.

	▲	tialaramex 12 hours ago \| parent [-]
		Arguably the C ABI was one of those Worse is Better problems like the C language itself. Better languages already existed, but C was basically free and easy to implement, so now there's C everywhere. It seems likely that if not for this ABI we might have an ABI today where all languages which want to offer FFI can agree on how to represent say the immutable slice reference type (Rust's &[T], C++ std::span) Just an agreed ABI for slices would be enough that language A's growable array type (Rust's Vec, C++ std::vector, but equally the ArrayList or some languages even call this just "list") of say 32-bit signed integers can give a (read only) reference to language B to look at all these 32-bit signed integers without language's A and B having to agree how growable arrays work at all. In C today you have to go wrestle with the ABI pig for much less.

▲

thayne 18 hours ago | parent | prev | next [-]

We should move away from it in C usage as well.

Ideally, the standard would include a type that packages a string with its length, and had functions that used that type and/or took the length as an argument. But even without that it is possible avoid using null terminated strings in a lot of places.

	▲	BobbyTables2 13 hours ago \| parent [-]
		The standard C library can’t even manipulate NUL terminated strings for common use cases… Simple things aren’t simple - want to append a formatted string to an existing buffer? Good luck! Now do it with UTF-8! I truly feel the standard library design did more disservice to C than the language definition itself.

▲

throwaway2037 2 hours ago | parent | prev | next [-]

Doesn't C++'s std::string also use a null terminated char* string internally? Do you count that also?

	▲	zabzonk an hour ago \| parent \| next [-]
		Since C++11 it is required to be null-terminated, you can access the terminator with (for e.g.) operator[], and the string can contain non-terminator null characters.
	▲	anal_reactor 2 hours ago \| parent \| prev [-]
		This doesn't count because it's implemented in a way "if you don't need null-terminated string, you won't see it".

▲

ofalkaed 4 hours ago | parent | prev [-]

>Which of course causes issues when languages with more proper strings interact with C but there you go.

Is is an issue of "more proper strings" or just languages trying to have their cake and eat it too? have their sense of a string and C interoperability. I think this is were we see the strength of Zig, it's strings are designed around and extend the C idea of string instead of just saying our way is better and we are just going to blame C for any friction.

My standard disclaimer comes into play here, I am not a programmer and very much a humanities sort, I could be completely missing what is obvious. Just trying to understand better.

Edit: That was not quite right, Zig has its string literal for C compatibility. There is something I am missing here in my understanding of strings in the broader sense.

▲

raverbashing 20 hours ago | parent | prev [-]

Yes

And maybe even have a (arch dependent) string buffer zone where the actual memory length is a multiple of 4 or even 8

▲

samshine 18 hours ago | parent | prev [-]

I haven't seen a strcpy use a scalar loop in ages. Is this an ARM thing?

▲

amluto 5 hours ago | parent | next [-]

Modern x86 CPUs have actual instructions for strcpy that work fairly well. There were several false starts along the way, but the performance is fine now.

▲

adrian_b 4 hours ago | parent [-]

They have instructions for memcpy/memmove (i.e. rep movs), not for strcpy.

They also have instructions for strlen (i.e. rep scasb), so you could implement strcpy with very few instructions by finding the length and then copying the string.

Executing first strlen, then validating the sizes and then copying with memcpy if possible is actually the recommended way for implementing a replacement for strcpy, inclusive in the parent article.

On modern Intel/AMD CPUs, "rep movs" is usually the optimal way to implement memcpy above some threshold of data size, e.g. on older AMD Zen 3 CPUs the threshold was 2 kB. I have not tested more recent CPUs to see if the threshold has diminished.

On the old AMD Zen 3 there was also a certain size range above 2 kB at sizes comparable with the L3 cache memory where their implementation interacted somehow badly with the cache and using "non-temporal" vector register transfers outperformed "rep movs". Despite that performance bug for certain string lengths, using "rep movs" for any size above 2 kB gave a good enough performance.

More recent CPUs might be better than that.

▲

amluto 39 minutes ago | parent | next [-]

Whoops, this proves I’m not really a userspace assembly programmer…

But you can indeed safely read past the end if a buffer if you don’t cross a page boundary and you aren’t bound by the rules of, say, C.

▲

gizmo686 4 hours ago | parent | prev [-]

X86-64 has the REP prefix for string operation. When combined with the MOVS instruction, that is pretty much an instruction for strcpy.

▲

messe 3 hours ago | parent [-]

No, it's an instruction for memcpy. You still need to compute the string length first, which means touching every byte individually because you can't use SIMD due to alignment assumptions (or lack thereof) and the potential to touch uninitialized or unmapped memory (when the string crosses a page boundary).

	▲	ncruces 2 hours ago \| parent [-]
		You do aligned reads, which can't crash. Not even musl uses a scalar loop, if it can do aligned reads/writes: https://git.musl-libc.org/cgit/musl/tree/src/string/stpcpy.c And you don't need to worry about C UB if you do it in ASM.

▲

manwe150 17 hours ago | parent | prev [-]

The spec and some sanitizers use a scalar loop (because they need to avoid mistakenly detecting UB), but real world libc seem unlikely to use a scalar loop.