fmemopen.3: Note various fmemopen() bugs that were fixed in glibc 2.22

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2016-03-02 16:03:03 +01:00
parent f435db47cd
commit 39ef79baad
1 changed files with 19 additions and 10 deletions

View File

@ -231,6 +231,10 @@ returned by these functions
(i.e.,
.BR fileno (3)
will return an error if called on the returned stream).
With version 2.22, many longstanding bugs in the implementation of
.BR fmemopen ()
were fixed, and a new versioned symbol was created for this interface.
.SH BUGS
In glibc before version 2.7, seeking past the end of a stream created by
.BR open_memstream ()
@ -239,26 +243,28 @@ does not enlarge the buffer; instead the
call fails, returning \-1.
.\" http://sourceware.org/bugzilla/show_bug.cgi?id=1996
If
In versions of glibc before 2.22, 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
.\" 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.
Furthermore, POSIX.1-2008 does not specify a failure for this case.
a stream that then returned end of file on the first attempt at reading;
since version 2.22, the glibc implementation provides that behavior.
Specifying append mode ("a" or "a+") for
In versions of glibc before 2.22,
specifying append mode ("a" or "a+") for
.BR fmemopen ()
sets the initial file position to the first null byte, but
.\" FIXME . http://sourceware.org/bugzilla/show_bug.cgi?id=13152
.\" http://sourceware.org/bugzilla/show_bug.cgi?id=13152
(if the file offset is reset to a location other than
the end of the stream)
does not force subsequent writes to append at the end of the stream.
This bug is fixed in glibc 2.22.
If the
In versions of glibc before 2.22, if the
.I mode
argument to
.BR fmemopen ()
@ -270,11 +276,13 @@ then, according to POSIX.1-2008,
the initial file position should be set to
the next byte after the end of the buffer.
However, in this case the glibc
.\" FIXME . http://sourceware.org/bugzilla/show_bug.cgi?id=13151
.\" http://sourceware.org/bugzilla/show_bug.cgi?id=13151
.BR fmemopen ()
sets the file position to \-1.
This bug is fixed in glibc 2.22.
To specify binary mode for
In versions of glibc before 2.22,
to specify binary mode for
.BR fmemopen ()
the \(aqb\(aq must be the
.I second
@ -282,10 +290,11 @@ character in
.IR mode .
Thus, for example, "wb+" has the desired effect, but "w+b" does not.
This is inconsistent with the treatment of
.\" FIXME . http://sourceware.org/bugzilla/show_bug.cgi?id=12836
.\" http://sourceware.org/bugzilla/show_bug.cgi?id=12836
.IR mode
by
.BR fopen (3).
This bug is fixed in glibc 2.22.
The glibc 2.9 addition of "binary" mode for
.BR fmemopen ()