only a few places left to convert to pkgconf_buffer_t in pkgconf now :)
-
only a few places left to convert to pkgconf_buffer_t in pkgconf now
and then we will be able to stop using strlcpy/strlcat (which was a bad engineering decision, but i was also much younger then)
-
only a few places left to convert to pkgconf_buffer_t in pkgconf now
and then we will be able to stop using strlcpy/strlcat (which was a bad engineering decision, but i was also much younger then)
@ariadne out of curiosity is that a you shouldn't use strlcpy/cat generally or it's just bad in your particular case
-
@ariadne out of curiosity is that a you shouldn't use strlcpy/cat generally or it's just bad in your particular case
@pius strlcpy/strlcat improve upon the memory safety of strncpy/strncat, but are almost always the wrong answer to a problem.
-
@pius strlcpy/strlcat improve upon the memory safety of strncpy/strncat, but are almost always the wrong answer to a problem.
@pius the correct approach is to use pascal-style strings, where the length is tracked
-
@pius the correct approach is to use pascal-style strings, where the length is tracked
-
@pius strlcpy/strlcat improve upon the memory safety of strncpy/strncat, but are almost always the wrong answer to a problem.
@ariadne @pius I was reading the string_copying(7) man page to remind me of what the different string copying functions do, and apparently it recommends using strtcpy and stpecpy instead of strlcpy and strlcat, both of which appear to have just been made up by the authors of that man page since it also says "This function is not provided by any library; see EXAMPLES for a reference implementation." -
R relay@relay.an.exchange shared this topic
