This is the mail archive of the 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]

On 2016-01-05 10:06, Paul Eggert 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.

Sorry, I don't understand what you mean. Your first reading of POSIX seems quite reasonable to me. And that reading conflicts with C11 so I reported it in .

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

It's not just Florian arguing about snprintf, it's the original article about strlcpy/strlcat referring to snprintf and OpenBSD man page unambiguously stating:

| Besides quibbles over the return type (size_t versus int) and signal
| handler safety (snprintf(3) is not entirely safe on some systems),
| the following two are equivalent:
|   n = strlcpy(dst, src, len);
|   n = snprintf(dst, len, "%s", src);

What I meant in my previous email is that these descriptions referred to C9X and BSD flavors of snprintf, not to the POSIX one. But now that we are agree to ignore POSIX for a moment, this detail is not important.

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.

Ok, I guess it boils down to the question which sources are considers authoritative for describing strlcpy/strlcat? Is OpenBSD man page included?

Alexander Cherepanov

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