This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug stdio/5994] fflush after ungetc on seekable input stream
- From: "eblake at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 17 Oct 2013 23:30:54 +0000
- Subject: [Bug stdio/5994] fflush after ungetc on seekable input stream
- Auto-submitted: auto-generated
- References: <bug-5994-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=5994
--- Comment #6 from Eric Blake <eblake at redhat dot com> ---
(In reply to Rich Felker from comment #5)
> I'm not clear what the current glibc behavior is. Does it reflect the Austin
> Group decision cited in the text of glibc bug 9754 (the one marked
> duplicate) or is it still somewhere in between the correct (per Austin
> Group) behavior and the (horribly wrong) behavior the original text of the
> standard demanded?
Current glibc behavior is still broken. The test program in this report is
what drove the Austin Group decision cited in glibc bug 9754.
When compiled, the foo.c in this report should output:
$ ./foo < foo.c
c = '#'
c = 'i'
ungetc result = '@'
after fflush, location = 1
c = 'i'
c = 'n'
$ ./foo 1 < foo.c
c = '#'
c = 'i'
ungetc result = 'i'
after fflush, location = 1
c = 'i'
c = 'n'
I tested on rawhide with glibc 2.18.90 gets it right in the second instance,
but is still broken in the first:
$ ./foo < foo.c
c = '#'
c = 'i'
ungetc result = '@'
after fflush, location = 581
c = 'n'
c = 'c'
--
You are receiving this mail because:
You are on the CC list for the bug.