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 14:09, Florian Weimer wrote:
On 01/05/2016 01:02 AM, Alexander Cherepanov wrote:

+The behavior of @code{strlcpy} is undefined if @var{size} is zero, or
+if the source and destination strings overlap.

I think it should say âif the source string and destination array
overlapâ.   There is no destination string before the call.  I don't
think it's necessary to make the special case defined where the source
string is part of the destination array, but not located close to the
beginning so that the actual copy will not overlap.  This is simply too
subtle.   I think it is undefined for snprintf (âIf copying takes place
between objects that overlap, the behavior is undefined.â),although
this does not necessarily follow from the restrict qualify (based on my
somewhat shaky understanding of restrict).

IIUC you are saying that this code:

No, my point was that this code:

   char s[10];
   strcpy (s + 5, "abc");
   snprintf (s, sizeof (s), "%s", s + 5);

is invalid.

Then my example is even more invalid (according to this logic).

This depends on what âobjectsâ means in âIf copying takes
place between objects that overlap, the behavior is undefined.â


   char s[10];
   snprintf(s, -1, "%s", "abc");

is invalid. IMHO this is wrong. 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, it just says that characters beyond
the (n-1)st are discarded.

POSIX, on the other hand, speaks of the ân argument which states the
size of the buffer referred to by sâ.

I'm not sure what you mean. That POSIX differs from ISO C and should be preferred here? Or that POSIX just describes the same in more details and that ISO C actually means the same? Or that authors of strlcpy/strlcat talked about the POSIX flavor of snprintf in their doc? Or something else?

Also: .

POSIX also requires that the -1
argument results in -1/EOVERFLOW result,

Yeah, clear contradiction with ISO C.

but this does not apply to
strlcpy because it has a size_t (not int) result.

I'm not sure what the intent behind these specifications is.  I would
certainly prefer that size arguments must denote object sizes.
Everything else is just extremely confusing.

Ok, I'm confused. I can see at least 3 different parts in drafting the specification of strlcpy/strlcat for glibc:
1) what was required/guaranteed by original strlcpy/strlcat,
2) what glibc is willing to break from it,
3) what glibc wants to add on top of it.

When you talk about snprintf analogy is it 1 or 3?

Which sources do you consider authoritative for 1? OpenBSD man page counts?

My impression was that snprintf analogy is in 1. And that this means that @var{size} is not required to be the size of the array.

For example, I don't expect

   read (fd, ptr, SSIZE_MAX)

to succeed as long as the actual number of bytes read is sufficiently
small (and it fails with EFAULT on Linux).

You mean that it violates POSIX and you like it? Hm...

I guess opinions will differ (as we have already seen with malloc(SSIZE_MAX+1)). But I would expect that all places where glibc intentionally deviates from the standards to be marked (at least). Are there such places already?

Alexander Cherepanov

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