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 03:52, Paul Eggert wrote:
On 01/04/2016 04:02 PM, Alexander Cherepanov wrote:
The description of snprintf in C11 doesn't mention size of the
destination array or talk about any connection between n and s at all,

True, but the POSIX description for snprintf (s, n, ...) has the
additional restriction that n must be the size of the buffer referred to
by s, so POSIX implementations of snprintf can assume that s's size is n
and that the destination array does not overlap any of the sources,
regardless of which parts of the destination are written to.

Are you seriously arguing for glibc not to comply with C11? I probably miss something about glibc...

OTOH [1] states (Excluding dprintf()): "The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of POSIX.1-2008 defers to the ISO C standard."


So, you just found a bug in POSIX. Cool!

Then, 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.


Finally, when the standard talks about objects that copying takes place between, it doesn't necessarily mean whole original objects. In most cases their sizes are not known at all. Well, 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?

Alexander Cherepanov

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