This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/20012] libio: fmemopen append mode failure
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 03 Jun 2016 18:15:32 +0000
- Subject: [Bug stdio/20012] libio: fmemopen append mode failure
- Auto-submitted: auto-generated
- References: <bug-20012-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=20012
--- Comment #4 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".
The branch, release/2.23/master has been updated
via 321e1cef26ccbece949b16622ef74c203bd8ecc6 (commit)
via c2fba3b047c2fac50985a47ff96075b5d9078432 (commit)
from 1915d6d182a55d1eb852643a78ac24bc17783fb0 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=321e1cef26ccbece949b16622ef74c203bd8ecc6
commit 321e1cef26ccbece949b16622ef74c203bd8ecc6
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date: Wed Apr 27 11:51:01 2016 -0300
libio: Fix fmemopen append mode failure (BZ# 20012)
The fmemopen implementation does not account the file position correctly in
append mode. The following example shows the failure:
===
int main ()
{
char buf[10] = "test";
FILE *fp = fmemopen (buf, 10, "a+");
fseek (fp, 0, SEEK_SET);
int gr;
if ((gr = getc (fp)) != 't' ||
(gr = getc (fp)) != 'e' ||
(gr = getc (fp)) != 's' ||
(gr = getc (fp)) != 't' ||
(gr = getc (fp)) != EOF)
{
printf ("%s: getc failed returned %i\n", __FUNCTION__, gr);
return 1;
}
return 0;
}
===
This is due both how read and write operation update the buffer position,
taking in consideration buffer lenght instead of maximum position defined
by the open mode. This patch fixes it and also fixes fseek not returning
EINVAL for invalid whence modes.
Tested on x86_64 and i686.
This is a backport of b65b205fbcabbb02463e31df17f5cabf7556f892.
[BZ #20012]
* libio/fmemopen.c (fmemopen_read): Use buffer maximum position, not
length to calculate the buffer to read.
(fmemopen_write): Set the buffer position based on bytes written.
(fmemopen_seek): Return EINVAL for invalid whence modes.
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=c2fba3b047c2fac50985a47ff96075b5d9078432
commit c2fba3b047c2fac50985a47ff96075b5d9078432
Author: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Date: Tue Apr 26 17:40:25 2016 -0300
libio: Update internal fmemopen position after write (BZ #20005)
Current GLIBC fmemopen fails with a simple testcase:
char buffer[500] = "x";
FILE *stream;
stream = fmemopen(buffer, 500, "r+");
fwrite("fish",sizeof(char),5,stream);
printf("pos-1:%ld\n",ftell(stream));
fflush(stream);
printf("pos-2:%ld\n",ftell(stream));
It returns:
pos-1:5
pos-2:0
Where it should return:
pos-1:5
pos-2:5
This is due the internal write function does not correctly update the
internal
object position state and then the seek operation returns a wrong value.
This
patch fixes it.
It fixes both BZ #20005 and BZ #19230 (marked as duplicated). A new test is
added to check for such case.
Tested on x86_64 and i686.
This is a backport of f9123b5003e62b6e54996076e860f23aee9a0593.
* libio/fmemopen.c (fmemopen_write): Update internal position after
write.
* stdio-common/Makefile (tests): Add tst-fmemopen4.c.
* stdio-common/tst-fmemopen4.c: New file..
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 14 +++
libio/fmemopen.c | 32 +++---
stdio-common/Makefile | 2 +-
stdio-common/tst-fmemopen3.c | 118 +++++++++++++++++++-
.../tst-rwlock13.c => stdio-common/tst-fmemopen4.c | 41 ++++----
5 files changed, 170 insertions(+), 37 deletions(-)
copy nptl/tst-rwlock13.c => stdio-common/tst-fmemopen4.c (53%)
--
You are receiving this mail because:
You are on the CC list for the bug.