* [Bug libc/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
@ 2011-09-05 2:06 ` bugdal at aerifal dot cx
2012-02-21 1:45 ` [Bug stdio/11216] " jsm28 at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: bugdal at aerifal dot cx @ 2011-09-05 2:06 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
2011-09-05 2:06 ` [Bug libc/11216] fmemopen returns NULL when len=0 bugdal at aerifal dot cx
@ 2012-02-21 1:45 ` jsm28 at gcc dot gnu.org
2012-04-27 20:22 ` mtk.manpages at gmail dot com
` (11 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: jsm28 at gcc dot gnu.org @ 2012-02-21 1:45 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
2011-09-05 2:06 ` [Bug libc/11216] fmemopen returns NULL when len=0 bugdal at aerifal dot cx
2012-02-21 1:45 ` [Bug stdio/11216] " jsm28 at gcc dot gnu.org
@ 2012-04-27 20:22 ` mtk.manpages at gmail dot com
2012-04-28 2:32 ` mtk.manpages at gmail dot com
` (10 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: mtk.manpages at gmail dot com @ 2012-04-27 20:22 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
` (2 preceding siblings ...)
2012-04-27 20:22 ` mtk.manpages at gmail dot com
@ 2012-04-28 2:32 ` mtk.manpages at gmail dot com
2012-04-28 3:22 ` mtk.manpages at gmail dot com
` (9 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: mtk.manpages at gmail dot com @ 2012-04-28 2:32 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
` (3 preceding siblings ...)
2012-04-28 2:32 ` mtk.manpages at gmail dot com
@ 2012-04-28 3:22 ` mtk.manpages at gmail dot com
2014-01-30 3:38 ` allachan at au1 dot ibm.com
` (8 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: mtk.manpages at gmail dot com @ 2012-04-28 3:22 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
` (4 preceding siblings ...)
2012-04-28 3:22 ` mtk.manpages at gmail dot com
@ 2014-01-30 3:38 ` allachan at au1 dot ibm.com
2014-01-30 4:04 ` eblake at redhat dot com
` (7 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: allachan at au1 dot ibm.com @ 2014-01-30 3:38 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
` (5 preceding siblings ...)
2014-01-30 3:38 ` allachan at au1 dot ibm.com
@ 2014-01-30 4:04 ` eblake at redhat dot com
2014-01-30 4:10 ` eblake at redhat dot com
` (6 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: eblake at redhat dot com @ 2014-01-30 4:04 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
` (6 preceding siblings ...)
2014-01-30 4:04 ` eblake at redhat dot com
@ 2014-01-30 4:10 ` eblake at redhat dot com
2014-01-30 4:23 ` allachan at au1 dot ibm.com
` (5 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: eblake at redhat dot com @ 2014-01-30 4:10 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
` (7 preceding siblings ...)
2014-01-30 4:10 ` eblake at redhat dot com
@ 2014-01-30 4:23 ` allachan at au1 dot ibm.com
2014-03-13 16:30 ` eblake at redhat dot com
` (4 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: allachan at au1 dot ibm.com @ 2014-01-30 4:23 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
` (8 preceding siblings ...)
2014-01-30 4:23 ` allachan at au1 dot ibm.com
@ 2014-03-13 16:30 ` eblake at redhat dot com
2014-03-13 16:37 ` eblake at redhat dot com
` (3 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: eblake at redhat dot com @ 2014-03-13 16:30 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
` (9 preceding siblings ...)
2014-03-13 16:30 ` eblake at redhat dot com
@ 2014-03-13 16:37 ` eblake at redhat dot com
2014-06-30 20:13 ` fweimer at redhat dot com
` (2 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: eblake at redhat dot com @ 2014-03-13 16:37 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
` (10 preceding siblings ...)
2014-03-13 16:37 ` eblake at redhat dot com
@ 2014-06-30 20:13 ` fweimer at redhat dot com
2015-07-08 15:13 ` adhemerval.zanella at linaro dot org
2015-08-03 14:10 ` schwab@linux-m68k.org
13 siblings, 0 replies; 14+ messages in thread
From: fweimer at redhat dot com @ 2014-06-30 20:13 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
` (11 preceding siblings ...)
2014-06-30 20:13 ` fweimer at redhat dot com
@ 2015-07-08 15:13 ` adhemerval.zanella at linaro dot org
2015-08-03 14:10 ` schwab@linux-m68k.org
13 siblings, 0 replies; 14+ messages in thread
From: adhemerval.zanella at linaro dot org @ 2015-07-08 15:13 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug stdio/11216] fmemopen returns NULL when len=0
[not found] <bug-11216-131@http.sourceware.org/bugzilla/>
` (12 preceding siblings ...)
2015-07-08 15:13 ` adhemerval.zanella at linaro dot org
@ 2015-08-03 14:10 ` schwab@linux-m68k.org
13 siblings, 0 replies; 14+ messages in thread
From: schwab@linux-m68k.org @ 2015-08-03 14:10 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 14+ messages in thread