Re: strscpy

Le 19/05/2020 à 18:00, Robert Elz a écrit :
> [...]

I see no reason to want to have a string copy function able to copy a terabyte
worth of string in the kernel -- above 1M, it's already a clear sign there is a
bug. I see no reason to try to use the bcopy() "correct arguments order"
(according to you) considering that bcopy() has been obsoleted by virtually
everyone long ago. Also, FYI, there is a difference between source ASM language
and compiled binary output (which is not "implemented in assembler on many
architectures", that just doesn't mean anything). And finally, I can't even
begin to count the thousands of problems we would be getting with a 16bit port;
never gonna happen on NetBSD.

Please stop talking nonsense, and let's stay on-topic.

More to the point: the overloading with negative errnos is typical in the linux
world, and I understand we may not want to use that convention in NetBSD. I
would therefore suggest my earlier version, which was using -1 as error code.



Le 19/05/2020 à 18:54, Kamil Rytarowski a écrit :
> On 19.05.2020 18:00, Robert Elz wrote:
>> Even with that, I still don't like overloading the result.
>
> OK... how about the previous version of strscpy() from Linux.
>
> static size_t strscpy(char *dest, const char *src, size_t size)
> {
> 	size_t len = strnlen(src, size) + 1;
> 	if (len > size) {
> 		if (size)
> 			dest[0] = '\0';
> 		return 0;
> 	}
> 	memcpy(dest, src, len);
> 	return len;
> }
>
> https://github.com/torvalds/linux/commit/bceb7efa6a7e656bfaa67b6f54925e7db75bcd52
>
> This one aborts on too long source. Would it match the NetBSD kernel needs?

But this one returns the size, not the length; the NUL terminator is counted.
This differs from strlcpy(), which doesn't count it; same for the aborting
behavior.

I would want to keep the difference minimal between the two. I think that the
version that returns -1 is nice and addresses the concern. What do you think?

Maxime