This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] [PATCH 2/2] libio: fmemopen rewrite to POSIX compliance
- From: Rich Felker <dalias at libc dot org>
- To: Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Sat, 21 Jun 2014 10:49:44 -0400
- Subject: Re: [RFC] [PATCH 2/2] libio: fmemopen rewrite to POSIX compliance
- Authentication-results: sourceware.org; auth=none
- References: <5398C951 dot 3020403 at linux dot vnet dot ibm dot com> <5398CC14 dot 7050507 at linux dot vnet dot ibm dot com> <87egyj6gqw dot fsf at rasmusvillemoes dot dk> <53A58F1D dot 9030802 at linux dot vnet dot ibm dot com>
On Sat, Jun 21, 2014 at 10:56:45AM -0300, Adhemerval Zanella wrote:
> On 20-06-2014 07:02, Rasmus Villemoes wrote:
> > Adhemerval Zanella <azanella@linux.vnet.ibm.com> writes:
> >
> >> This patch added a new fmemopen version, for glibc 2.20, that aims to be
> >> POSIX complaint.
> > [snip]
> >
> >> FILE *
> >> -fmemopen (void *buf, size_t len, const char *mode)
> >> +__fmemopen (void *buf, size_t len, const char *mode)
> >> {
> >> cookie_io_functions_t iof;
> >> fmemopen_cookie_t *c;
> >>
> >> if (__glibc_unlikely (len == 0))
> >> {
> >> - einval:
> >> __set_errno (EINVAL);
> >> return NULL;
> >> }
> > Regarding this, note that POSIX is changing [1] to allow, and in the future
> > maybe even require, fmemopen(s, strlen(s), "r") to work, even if s
> > happens to be an empty string. IMHO, the only sane semantics for
> > fmemopen with a length of 0 is to behave like /dev/null (when reading)
> > and /dev/full (when writing).
> >
> > [1] http://austingroupbugs.net/view.php?id=818
> >
> > Rasmus
> >
> Thanks for the input. My understanding from note [2] from the link you cited:
>
> ---
> Add a new paragraph after 29200:
>
> [EINVAL] The size argument specifies a buffer size of zero and the implementation does not support this.
> ---
>
> Indeed allows zero size buffer to return EINVAL, as noted in comment #11 in
> https://sourceware.org/bugzilla/show_bug.cgi?id=11216.
>
> I checked some other libc implementations and there is no consensus about how to act
> on zero length buffer:
>
> * FreeBSD: accepts zero length buffer
> http://svnweb.freebsd.org/base/stable/10/lib/libc/stdio/fmemopen.c?revision=256281&view=markup
>
> * Newlib: returns EINVAL
> https://www.sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/stdio/fmemopen.c?rev=1.5&content-type=text/x-cvsweb-markup&cvsroot=src
>
> * musl: returns EINVAL
> http://git.musl-libc.org/cgit/musl/tree/src/stdio/fmemopen.c
>
> So I am not sure which direction to follow in such case.
IIRC I only did the EINVAL thing in musl reluctantly because POSIX
required it at the time. I'm happy to change it. As long as the rest
of the specification is sufficient to define how a size-0 buffer would
behave, that's all that should matter. If it's not, we need more
discussion/clarification with/from the Austin Group.
Rich