[Bug libc/11216] fmemopen returns NULL when len=0

[Bug libc/11216] fmemopen returns NULL when len=0

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=11216

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |bugdal at aerifal dot cx
         Resolution|WONTFIX                     |

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> 2011-09-05 02:06:05 UTC ---
Nowadays fmemopen is specified by POSIX 2008, and POSIX 2008 has no language
that it shall or may fail if the size is 0. I think this bug should be
reconsidered.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[jsm28 at gcc dot gnu.org]

http://sourceware.org/bugzilla/show_bug.cgi?id=11216

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libc                        |stdio

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[mtk.manpages at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11216

Michael Kerrisk <mtk.manpages at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mtk.manpages at gmail dot
                   |                            |com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[mtk.manpages at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11216

Michael Kerrisk <mtk.manpages at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eblake at redhat dot com

--- Comment #4 from Michael Kerrisk <mtk.manpages at gmail dot com> 2012-04-28 02:29:48 UTC ---
Adding Eric Blake to the CC, since he may be interested in this bug from a
POSIX perspective.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[mtk.manpages at gmail dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=11216

--- Comment #5 from Michael Kerrisk <mtk.manpages at gmail dot com> 2012-04-28 03:21:41 UTC ---
I've added the following text to the fmemopen(3) man page:

[[
If
.I size
is specified as zero,
.BR fmemopen ()
fails with the error
.BR EINVAL .
.\" FIXME http://sourceware.org/bugzilla/show_bug.cgi?id=11216
It would be more consistent if this case successfully created
a stream that then returned end of file on the first attempt at reading.
]]

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[allachan at au1 dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11216

paxdiablo <allachan at au1 dot ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allachan at au1 dot ibm.com

--- Comment #6 from paxdiablo <allachan at au1 dot ibm.com> ---
I'm not entirely sure why is this being considered a bug.

The 2013 publication of POSIX.1 at
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fmemopen.html
specifically states (in the return value section):

===
The fmemopen() function shall fail if:
[EINVAL]
    The size argument specifies a buffer size of zero.
===

Hence returning NULL seems to be the RIGHT thing to do.

People may well believe it's more consistent to allow it and fail on first
read, but that's not what POSIX says to do. "Shall" in standards context means
"must", there's no room for movement there unless you want to claim
non-compliance with said standard :-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[eblake at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11216

--- Comment #7 from Eric Blake <eblake at redhat dot com> ---
(In reply to paxdiablo from comment #6)
> I'm not entirely sure why is this being considered a bug.

POSIX defined fmemopen using glibc as its reference implementation - we could
just as easily argue that glibc is correct and POSIX is in error for requiring
failure on len=0.

> People may well believe it's more consistent to allow it and fail on first
> read, but that's not what POSIX says to do. "Shall" in standards context
> means "must", there's no room for movement there unless you want to claim
> non-compliance with said standard :-)

Or claim that said standard was incorrect in what it requires.  I've gone ahead
and opened http://austingroupbugs.net/view.php?id=818 - let's wait until that
has an answer from the POSIX folks before deciding what to do here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[eblake at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11216

--- Comment #8 from Eric Blake <eblake at redhat dot com> ---
While we're at it, the POSIX folks have a question for glibc:
http://austingroupbugs.net/view.php?id=657
http://sourceware.org/bugzilla/show_bug.cgi?id=15298

The glibc behavior is not very well documented nor very intuitive, and POSIX is
stuck trying to determine if glibc and/or the standard needs updating.  How
much room do we have for improving things?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[allachan at au1 dot ibm.com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11216

--- Comment #9 from paxdiablo <allachan at au1 dot ibm.com> ---
> POSIX defined fmemopen using glibc as its reference implementation - we could just as easily argue that glibc is correct and POSIX is in error for requiring failure on len=0.

Except for the near-fatal flaw in your contention, that _POSIX_ is the
standard, not glibc :-)

> Or claim that said standard was incorrect in what it requires.  I've gone ahead
and opened http://austingroupbugs.net/view.php?id=818 - let's wait until that
has an answer from the POSIX folks before deciding what to do here.

No probs. My view is that it's set in stone now until they change it in a
future edition. There's no real getting around the "shall" language in the
_very_ specific text of the standard dealing with the return code, that's not
something that slips in inadvertently, it was a very conscious decision.

So, as long as we're clear this isn't (pending POSIX resolution of the issue
you raised) currently a bug in glibc itself (and someone's not going to go off
half-cocked and "fix" it), it's probably best to leave it open.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[eblake at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11216

--- Comment #10 from Eric Blake <eblake at redhat dot com> ---
Hooray! POSIX relaxed their spec today.  Unless objections are raised before
the 30-day review completes, the pre-POSIX behavior of treating a 0 length
buffer as a valid empty file similar to /dev/null is now permitted for Issue 7,
and future directions says it will probably even be required in Issue 8.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[eblake at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11216

--- Comment #11 from Eric Blake <eblake at redhat dot com> ---
(In reply to Eric Blake from comment #10)
> Hooray! POSIX relaxed their spec today.

http://austingroupbugs.net/view.php?id=818#c2184
"
Delete line 29196.

Add a new paragraph after 29200:

    [EINVAL] The size argument specifies a buffer size of zero and the
implementation does not support this.


Add to Future Directions after line 29235

A future revision of this standard may require support of zero length buffer
streams explicitly.
"

Basically, the shall fail was relaxed to a mail fail, with the intent of
removing the failure altogether and instead requiring successful use of a
0-length memstream, back to the original glibc behavior.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=11216

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=11216

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg
         Resolution|---                         |FIXED

--- Comment #12 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
With this latest clarification and recent new fmemopen implementation
(fdb7d390dd0d96e4a8239c46f3aa64598b90842b) I am closing this bug.

If and when the spec changes to 'shall not fail' we can reopen or create
another tracking BZ.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug stdio/11216] fmemopen returns NULL when len=0

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=11216

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at redhat dot com

--- Comment #13 from Andreas Schwab <schwab@linux-m68k.org> ---
*** Bug 18756 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are on the CC list for the bug.