3 ms·
This was my reaction as well. Banning strncpy just encourages haphazard manual copying.
by dahfizz 6y ago
This was my reaction as well. Banning strncpy just encourages haphazard manual copying.
- asdfasgasdgasdg 6y agoI think you're meant to use snprintf instead. It would be great to see documentation on the alternatives!
- smasher164 6y agoFrom the commit message: If you're thinking about using it, consider instead: - strlcpy() if you really just need a truncated but NUL-terminated string (we provide a compat version, so it's always available) - xsnprintf() if you're sure that what you're copying should fit - strbuf or xstrfmt() if you need to handle arbitrary-length heap-allocated strings
- nwmcsween 6y agostrlcpy is safer but effectively running strlen(src) every call is a good wtf
- azurezyq 6y agomaybe this https://github.com/git/git/blob/master/strbuf.h https://github.com/git/git/blob/master/strbuf.h ?
- ben_bai 6y agostrlcpy is the safe way, that is used by git.
- deleted 6y ago[deleted]
- syncsynchalt 6y agostrncpy doesn't do what you think it does (it is not analogous to strncat). strncpy does not terminate strings on overflow. In C terms, it is not actually a string function and shouldn't be named with `str`. snprintf or nul-plus-strncat do what you want, but snprintf has portability problems on overflow. Most projects I've been on rely on strlcpy (with a polyfill implementation where not available).
- dahfizz 6y agostrnlen may be surprising the first time you see it not null terminate, sure. But if you use the n version of all the string functions (which you should anyway) then it's safe.