This is the mail archive of the
mailing list for the glibc project.
Re: [PING][PATCH v2] Remove check for NULL buffer passed to `ptsname_r'
- From: Zack Weinberg <zackw at panix dot com>
- To: Arjun Shankar <arjun dot is at lostca dot se>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>
- Date: Wed, 7 Jun 2017 10:15:28 -0400
- Subject: Re: [PING][PATCH v2] Remove check for NULL buffer passed to `ptsname_r'
- Authentication-results: sourceware.org; auth=none
- References: <20170607115039.GB65837@aloka.lostca.se> <CAKCAbMiO4iy9_jLFKbWfKumo8=VpQTkg1hr2noM06g1DDcBtqg@mail.gmail.com> <20170607140956.GA67039@aloka.lostca.se>
On Wed, Jun 7, 2017 at 10:09 AM, Arjun Shankar <email@example.com> wrote:
> On Wed, Jun 07, 2017 at 09:39:40AM -0400, Zack Weinberg wrote:
>> Is this function documented in our manual (manual/*.texi)? If so,
>> please update that.
> The function is documented, but there is no reference to EINVAL and no
> hint that a NULL buf is handled in any way. Here is the relevant text
> (source is in manual/terminal.texi):
>> -- Function: int ptsname_r (int FILEDES, char *BUF, size_t LEN)
>> Preliminary: | MT-Safe | AS-Unsafe heap/bsd | AC-Unsafe mem fd |
>> *Note POSIX Safety Concepts::.
>> The ptsname_r function is similar to the ptsname function
>> except that it places its result into the user-specified buffer
>> starting at BUF with length LEN.
>> This function is a GNU extension.
> Given this, I propose that we leave the this section unchanged.
I agree. We don't normally bother saying that passing a null pointer
to a function may cause a crash - in fact, it's the other way around,
we specifically document when null *is* allowed.
>> OK with that change. I don't think we need a copyright assignment for
>> a change that deletes seven lines of code and adds none.
> Even otherwise, I have an assignment on file, and I recently got commit
> access in git :)
Oh, sorry about that. I didn't recognize your name.