This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug stdio/5994] fflush after ungetc on seekable input stream


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]