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

[Alexander Cherepanov <ch3root at openwall dot com>]

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.â

Ok

> >    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: http://austingroupbugs.net/view.php?id=1020 .

> 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