This is the mail archive of the
mailing list for the glibc project.
Re: Fix BZ 18756 (fmemopen(..., 0, ...) does not fail)
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Rasmus Villemoes <rv at rasmusvillemoes dot dk>, GLIBC Devel <libc-alpha at sourceware dot org>
- Cc: Paul Pluzhnikov <ppluzhnikov at gmail dot com>
- Date: Mon, 03 Aug 2015 16:31:35 -0300
- 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> <87wpxcbilh dot fsf at rasmusvillemoes dot dk>
Thanks for remind about this one (something was lingering in my head saying
this has already been addressed).
On 03-08-2015 10:35, Rasmus Villemoes wrote:
> On Mon, Aug 03 2015, Adhemerval Zanella <firstname.lastname@example.org> wrote:
>> 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