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: Rasmus Villemoes <rv at rasmusvillemoes dot dk>
- To: libc-alpha at sourceware dot org
- Date: Fri, 20 Jun 2014 12:02:31 +0200
- 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>
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