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

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

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