strlcpy returns offset of dst + len of src which requires strlen(src) which isn't optional and sort of sucks imo.
Something very similar but that doesn't do strlen(src) such as https://godbolt.org/g/Etpuhz would be better.
Well one could argue that in C a string is not a string unless it's NUL terminated...
It's a choice they made to make it easy to detect truncation. If you don't care about the return value of strlcpy you can modify it to skip that part (which IMO will make it worse) but get rid of traversing src until \0 is found.
If you know you're working with non-terminated "strings" then just use memcpy instead.
If you're using proper functions you shouldn't end up with a non NUL-terminated string in the first place, although there are shortcomings in the commonly used libraries here unfortunately yes. It's hard to create a function that solves all problems.
(Side note: IMO The return value of latest OpenBSD version of strlcat (cat not cpy) is a bit weird when size is smaller than strlen(dst))
My issue isn't that src is or isn't NUL terminated (strings in c absolutely must be NUL terminated) its that strlcpy requires a call to strlen (probably inlineable with lto) which is going to be a lot slower than not. Also there is a bug in my 'strmcpy' in the last for loop it should be n && *s
