← Back to context

Comment by eatbitseveryday

2 years ago

Linux uses strscpy. See [1] [2] [3]. The issues of concern are to always NUL-terminate, and to effectively know if the result was truncated.

Truncation can lead to big issues, especially if the string being composed refers to paths, device names, other resources, etc. For example you may truncate a path from /foo/bar/baz to /foo/bar and inadvertently operate on other files. An API that makes this confusing is dangerous.

See the confused deputy problem description [4].

[1] https://mafford.com/text/the-many-ways-to-copy-a-string-in-c...

[2] https://lwn.net/Articles/659214/

[3] https://docs.kernel.org/core-api/kernel-api.html#c.strscpy

[4] https://en.wikipedia.org/wiki/Confused_deputy_proble

10 comments

eatbitseveryday

Reply
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)

  • 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'.

      4 replies →