On Fri, Nov 10, 2023 at 09:58:42AM -0800, Paul Eggert wrote: > On 2023-11-10 03:05, Alejandro Colomar wrote: > > Hopefully, it won't be so bad in terms of performance. > > It's significantly slower than strncpy for typical use (smallish fixed-size > destination buffers). So just use strncpy for that. It may be bad, but it's Do you have any numbers? I'm curious to see strnlen+memcpy vs stpncpy for buffers of some typical sizes (say 80 and BUFSIZ) under amd64 and arm64 (two typical archs). Are we talking of 1%, 10%, or 100%? > better than the alternatives you've mentioned. You can package strncpy > inside a [[nodiscard]] inline wrapper if you like. > > More importantly, the manual should not push strlcpy as being superior or > being in any way a "fix" for strncpy's problems. strlcpy is worse than > strncpy in important ways and besides - as mentioned in the glibc manual - > neither function is a good choice for string processing. -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
