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

[Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>]

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.