This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fix BZ 18756 (fmemopen(..., 0, ...) does not fail)
- From: Rasmus Villemoes <rv at rasmusvillemoes dot dk>
- To: GLIBC Devel <libc-alpha at sourceware dot org>
- Cc: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Paul Pluzhnikov <ppluzhnikov at gmail dot com>
- Date: Mon, 03 Aug 2015 15:35:22 +0200
- Subject: Re: Fix BZ 18756 (fmemopen(..., 0, ...) does not fail)
- Authentication-results: sourceware.org; auth=none
- References: <CALoOobNoDoSCD2bTsgY-CkHtSmwMcXk0fmvK5Vbgc9XpeGWi-w at mail dot gmail dot com> <55BF5F66 dot 3050706 at linaro dot org>
On Mon, Aug 03 2015, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
> Hi,
>
> Thanks for the patch, it straightforward enough. Only a comment below.
>
But why? What happened to
https://sourceware.org/bugzilla/show_bug.cgi?id=11216 ?
What I_WANT_SANE_FMEMOPEN_SEMANTICS flag should I set to avoid having to
special-case the empty string in fmemopen(s, strlen(s), "r")?
Why should a memory buffer which happens to be of length 0 be treated
any differently than fopen() of an empty file [or /dev/full in the case
of writing]? Or put another way, in what scenario is it useful for
fmemopen() to return NULL/errno==EINVAL when len==0?
"The standard says/said so" is not a valid reason: that would just imply
that the standard is broken. Which they sort-of seem to have
acknowledged. Please, let's keep trying to steer the supertanker in the
right direction instead of mindlessly following it along its misdirected
course.
Rasmus