This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178]


Alexander Cherepanov wrote:

it's handy

No, because even if that example's silent-truncation bug were fixed (which is yet another bit of evidence against strlcpy!), its use case is already well-addressed by the standard API, and portable programs can (and already do) use something like the following instead.

  void
  cpy_with_growing (char **dest, char const *src, size_t *size)
  {
    size_t s = strlen (src) + 1;
    if (*size <= s)
      {
	free (*dest);
        size_t doubled = 2 * *size;
	*size = s <= doubled ? doubled : s;
	*dest = xmalloc (*size);
      }
    memcpy (*dest, src, s);
  }

you can catch size=0 with strlcat even if strlcpy accepts size=0 without triggering any protections.

No, because often only strlcpy is executed, with strlcat used only in relatively unusual circumstances. There are sound software-engineering reasons for insisting that strlcpy be no less reliable and strict than strlcat, and for the two functions to follow the same rules.

be conservative in what you document, be liberal in what you implement.

Yes, that's a goal of my most recently-proposed documentation. Again, I don't think we should add strlcpy+strlcat to glibc; but if we do add them, we should document them conservatively.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]