← Back to context

Comment by dchest

2 years ago

Here's discussion on why strscpy shouldn't be included in POSIX:

https://www.austingroupbugs.net/view.php?id=986 (scroll to 0002897)

8 comments

dchest

Reply
saagarjha  2 years ago

It's not a very good argument. Notably:

> strlcpy() fits within the existing set of functions like a glove. strlcpy(a, b, n) behaves identically to snprintf(a, n, "%s", b). The return value always corresponds to the number of non-null bytes that would have been written. If we truly think that this is bad design, should we come up with a new version of snprintf() that also doesn't do this? I don't think so.

People typically do not consider snprintf and strlcpy to be a similar family of functions. There's no need to transpose the weird behavior to a new string copying routine.

  • yyyk  2 years ago

    You're latching to one minor point and ignoring main points like 'According to POSIX we can't define strscpy's return value', and 'We are standardizing a widely used function while strscpy is used in exactly one place - and a strscpy which fixes the return value is used nowhere'.

    • saagarjha  2 years ago

      I don’t actually care what it returns as long it’s something that doesn’t take O(n) to compute. Feel free to rename it too if you don’t want it to be confused with strscpy.

      3 replies →