strscpy() and the hazards of improved interfaces

Heck, if you put a gateway between the highly-tested parts and the others you are half way to a micro-kernel 8-)

That said, it doesn't mean that the hardware actually works that way. As far as testing goes, this would be a big step forward, but still not quite a substitute for having the actual hardware to test against.

QEMU is a remarkable piece of software, made even better by KVM. It enables lots of things that would have been difficult or tedious before, like this sort of testing. It could use more documentation, but it's well worth spending some time with to see what it can offer.

1) There is going to be someone somewhere which depends on that behaviour(!)
2) The code might be there but not in the immediate area so you'd miss it with mass replace (i.e the safety checks are performed up the call chain so you'd end up adding unnecessary code because "you" thought there was a preexisting bug because the code isnt understood enough.

Only when dst is shorter than src right?

> Not only this slows thing down for no good reason

The reason is to inform the caller how large dst needs to be for success in the case of a failure. That seems like a very good reason to me. I doubt the extra slowness would be measurable in a typical use case.

Regarding not checking the return value: many times strlcpy is replacing code that already didn't check for the return value, and added as a stop-gap. More importantly, not checking for a return value is not always a bug, or even usually a bug, in the contexts where you add strlcpy. Checking the return value is neither necessary nor sufficient as a general matter; it's context specific.[1] If the semantics of the code are garbage-in, garbage-out, then not checking for truncation is not necessary. If the semantics are that truncated input could subvert some condition, then checking for truncation is not always sufficient. Coding an algorithm so that garbage-in is safely garbage-out is arguably the most robust way to write secure code. If the data is highly structured, you probably shouldn't be using C strings much. Separating constraint checks from the core algorithm that processes input is an anti-pattern when writing secure code--it's usually better to put constraints on the _actual_ state of the algorithm processing the input. This is why, for example, Lua removed it's bytecode validator--it was neither necessary nor sufficient, and in practice added needless complexity; remove needless complexity and it becomes easier to focus on finding and fixing bugs in the code that matters.

And strscpy is hardly better relative to strlcpy weak points. strscpy overloads the return value just like strlcpy does. If you don't check for a failure condition, the length will be too large (extremely large in the case of (size_t)-E2BIG). And nothing inherent in strscpy forces a developer to check for truncation.

You could argue truncation checking is slightly less prone to bugs. The obvious issue with strlcpy is using n > lim instead of n >= lim to compare, an off-by-one. But I could just as easily envision people doing n <= 0 or n == E2BIG instead of n < 0 or n == -E2BIG with strscpy. What matters is the _idiom_ that people will use and adopt. And in any event, in both case the misuses are fairly easy to locate using pattern matching.

It's a shame that so many otherwise rational people have adopted such an irrational aversion to strlcpy. There's so much poor reasoning involved. Even if it was the worst interface in the world, the situation is compounded by creating conditions where people constantly reimplement it, often with bugs. It's widely included in many projects; attempts at berating people into not using it have manifestly failed. It's like the war on drugs. Yes, drugs harm society--largely as a result of abuse by a small subset of individuals (sorta like the specter of strlcpy misuses). Yes society would be better off without drugs. And yet banning them does't work.

[1] Grepping for an unchecked strlcpy in the OpenBSD source tree, the first hit brings me to line 776 in bin/csh/csh.c. rechist is copying a command-line into the history buffer. It's old, crufty code, dating to the 1980s. That edit was made in 2003 and replaced a use of strcpy. There's no easy way to bubble up a truncation error, and panicing or exiting failure on a truncation could break existing code; indeed it could introduce security issues of its own by obscuring the exit status of the command. And truncation in this context is about as benign as these things come in the real world. Would you suggest refactoring all of the logic in csh related to management of the history buffer? Make it all dynamicalliy allocated, as GNU developers insist upon? Reject command-lines longer than a record buffer when in interactive sessions? Yeesh.

A more likely design choice at the time would have been the UCSD Pascal scheme in which the first bytes of the char array contain the length. On the PDP-11, a two-byte length was sufficient. But that would have given up the convenience that a pointer to string is a pointer to the first byte of its data, allowing the same function to take either a string or a non-string buffer, e.g.
write(1, "Hello, world\n", 13).

Buffer overflow wasn't on the radar much for 16-bit machines. We had so little space that we took better care of it. Then the 32-bit VAX came along and that discipline went by the wayside.

(See also opinions on AT&T versus Intel assembly syntax.)

Yes, I know that read(), gettimeofday(), getrusage(), getrlimit() and others have the destination buffer last, but they seem like the odd ones out to me.

(My sense of tidyness is less aggravated by the *_r() functions, as creating an updated API by appending a parameter to the new function seems less disruptive than reordering the existing parameters.)