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: [RFC] [PATCH 2/2] libio: fmemopen rewrite to POSIX compliance

On 20-06-2014 07:02, Rasmus Villemoes wrote:
> Adhemerval Zanella <> 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]
> 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

I checked some other libc implementations and there is no consensus about how to act
on zero length buffer:

* FreeBSD: accepts zero length buffer

* Newlib: returns EINVAL

* musl: returns EINVAL

So I am not sure which direction to follow in such case.

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