Re: [RFC] [PATCH 2/2] libio: fmemopen rewrite to POSIX compliance

[Rich Felker <dalias at libc dot org>]

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