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: 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 <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
>