This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178]
- From: Alexander Cherepanov <ch3root at openwall dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 7 Jan 2016 23:38:52 +0300
- Subject: Re: [PATCH v7] Implement strlcpy, strlcat [BZ #178]
- Authentication-results: sourceware.org; auth=none
- References: <5682DD7E dot 6000301 at redhat dot com> <56839678 dot 8040304 at cs dot ucla dot edu> <568ADC5F dot 5010608 at redhat dot com> <568B0824 dot 6000101 at openwall dot com> <568BA474 dot 2030104 at redhat dot com> <568C33A5 dot 8020104 at openwall dot com> <568C4CAA dot 6080607 at redhat dot com>
On 2016-01-06 02:07, Florian Weimer wrote:
On 01/05/2016 10:20 PM, Alexander Cherepanov wrote:
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?
My point is that we are reading too much into those texts. I can only
assume that the POSIX authors assumed their formulation was equivalent
when it clearly is not. This means that some clarification is needed
(both in ISO C and POSIX) to decide what we really want (which, at this
stage should be what existing implementations do, if they are aligned,
but people working standards have sometimes different ideas about how to
deal with such ambiguities), or if things should be left unspecified or
implementation-defined.
I don't think this is applicable to ISO C in this particular case. In
questions "size of object vs. number of chars to copy" and "string vs.
non-null-terminated array" it seems quite accurate and consistent. I
doubt there is a chance to change something here. There even was a
movement in the direction opposite to what you want -- it was clarified
in C11 for memchr that an implementation cannot go further after a
matching character is found (s.a. glibc bug 19406).
OTOH POSIX is quite sloppy in this area. Apart from the snprintf issue,
I recently reported a strndup issue --
http://austingroupbugs.net/view.php?id=1019 . I mainly aimed at
consistency with other strn* functions, maybe you want to chime in with
other considerations.
Sure, C11 has its own problems, bugs and crazy defect reports but IMHO
they are more advanced.
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?
1) for strlcpy. For strlcat, I don't think anymore I can make this case.
Which sources do you consider authoritative for 1? OpenBSD man page counts?
The current (amended) OpenBSD manual page.
Ok, thanks.
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.
Doesn't OpenBSD snprintf has the bounded pointer check?
Whether they calculate s+n? AFACT no but it's possible that I missed it.
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 don't think it violates POSIX. I think the text was not written with
this level of exegesis in mind.
Maybe. I don't have enough experience with POSIX to judge it. But the
problem with such POV is that a standard, once published, starts to live
its own life. No matter what its authors thought or intended other folks
work with the published text.
OTOH, is this intentional behavior of read on Linux? Is there a
consensus around it? If yes, why not submit it to POSIX?
--
Alexander Cherepanov