Skip to contentSkip to conversation

New: fflush(3) is misleading about input streams

Bug 91931 bugzilla-daemon-590EEB7GvNiWaY/[email protected] 1 participant 5 messages Jan 23, 2015 – Jan 28, 2015 1 message not in the archive Man-pages: manual pages for Linux -- Sections 2, 3, 4, 5, and 7

lore
Share & tools
lore
#0 lore raw

https://bugzilla.kernel.org/show_bug.cgi?id=91931

Bug ID: 91931
Summary: fflush(3) is misleading about input streams
Product: Documentation
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: man-pages
Assignee: documentation_man-pages-ztI5WcYan/[email protected]
Reporter: [email protected]
Regression: No

Current fflush(3) claims that

"For input streams, fflush() discards any buffered data that has been fetched from the underlying file, but has not been consumed by the application."

While technically true (assuming 'file' implies seekable device), this is
incomplete: flushing an input stream associated with a non-seekable device, such as the terminal input, does nothing (the update to fp->_IO_read_end at libio/fileops.c:872 does not happen due to ESPIPE from lseek)

There have been enough confused beginner posts to various internet forums asking why flushing stdin doesn't work on Linux. I believe it is worth making the man page more explicit. At the very least, it should begin that sentence with "For input streams associated with seekable devices", or perhaps it should mention the unfortunately popular use case fflush(stdin) explicitly.

On a very minor note, fflush(3) also claims that "The standards do not specify the behavior for input streams"

This is no longer precisely correct; POSIX specifies behavior for seekable input streams to move fileno's offset to match FILE's offset and undo all ungetc's: http://pubs.opengroup.org/onlinepubs/9699919799/functions/fflush.html
and glibc conforms to that (or tries to,
https://sourceware.org/bugzilla/show_bug.cgi?id=5994 is still open)

Signature · 6 lines
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#2 lore raw

[Bug 91931] fflush(3) is misleading about input streams

In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=91931

Michael Kerrisk <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Michael Kerrisk <[email protected]> --- Thanks for the report. I think you are more or less right. One question though:
should the text not be in terms of "block buffered stream" rather than "seekable device"?

Thanks,

Michael

Signature · 6 lines
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#3 lore raw

[Bug 91931] fflush(3) is misleading about input streams

In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=91931

--- Comment #2 from [email protected] --- I don't see how buffering strategy would be relevant: it calls lseek(2) the same way whether the streams are setvbuf'd line-buffered or block-buffered.

POSIX wording is simply "the file is one capable of seeking"

Signature · 6 lines
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#4 lore raw

[Bug 91931] fflush(3) is misleading about input streams

In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=91931

--- Comment #3 from Michael Kerrisk <[email protected]> --- (In reply to cubbi from comment #0)

Quoted 9 lines

On a very minor note, fflush(3) also claims that "The standards do not specify the behavior for input streams"

This is no longer precisely correct; POSIX specifies behavior for seekable input streams to move fileno's offset to match FILE's offset and undo all ungetc's:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/fflush.html and glibc conforms to that (or tries to,
https://sourceware.org/bugzilla/show_bug.cgi?id=5994 is still open)

Thanks. I modified the text to note that POSIX.1-2008 does add specification for input streams.

Signature · 6 lines
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#5 lore raw

[Bug 91931] fflush(3) is misleading about input streams

In reply to a message not in the archive

https://bugzilla.kernel.org/show_bug.cgi?id=91931

Michael Kerrisk <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |CODE_FIX
Signature · 6 lines
You are receiving this mail because:
You are watching the assignee of the bug.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html