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:
Are you seriously arguing for glibc not to comply with C11?

Naaah. And on second thought, my comment was based on a backwards interpretation of the POSIX spec: that spec places extra constraints on the implementation not on the application. So please forget my mistaken comment about POSIX snprintf.

descriptions (e.g. [2], [3]) of strlcpy and strlcat refer to C9X or BSD,
not to POSIX. So it's not relevant to the current discussion.

Yes and no. I think Florian is arguing that strlcpy should act like snprintf, and so in that sense it's relevant. However, I agree with you that snprintf is not an exact analog and is not a good precedent for strlcpy.

do you think the fact that @var{to} and @var{from}
overlap makes the code:

   char s[10] = "abc";
   strncat(s, s, 2);

is invalid even though there is no overlapping copying?

I don't think strncat is an exact analog for strlcat either. That is, although I agree that the strncat example has well-defined behavior in C11, this is not precedent for strlcat, any more than snprintf would be. They're just different functions, that's all.

For example, it'd be reasonable for strlcpy to verify that every byte in the destination array is writeable. That could help catch bugs in programs. The spec should not disallow such an implementation.


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