Bug 108118 - [libc] files should not cache their EOF status
Summary: [libc] files should not cache their EOF status
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-19 14:30 UTC by Trenton Schulz
Modified: 2018-01-03 05:14 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Trenton Schulz 2007-01-19 14:30:17 UTC
When opening one file handle for reading binary and another for writing
binary, one can write a byte, flush the file, and then attempt to read
two bytes, the function will fail to read the one byte.

This does not happen on HP-UX, AIX, or Linux

Fix: 

The programmer can call fseek() and try again. But it's a bit of second
guessing. I guess it shouldn't cache the eof check.
How-To-Repeat: #include <stdio.h>
#include <assert.h>

int main()
{
    FILE *writeFile;
    FILE *readFile;
    char readChar;
    int i;

    writeFile = fopen("/tmp/fooFile", "wb");
    readFile = fopen("/tmp/fooFile", "rb");

    for (i = 0; i < 2; i++) {
        fwrite("a", 1, 1, writeFile);
        fflush(writeFile);
        assert(fread(&readChar, 1, 2, readFile) > 0);
    }
    return 0;
}
Comment 1 Jilles Tjoelker freebsd_committer 2009-04-04 15:56:29 UTC
The way I read POSIX, FreeBSD's current behaviour seems correct. Calling
fread(3) is equivalent to calling fgetc(3) an appropriate number of
times, and fgetc(3) shall fail if the end-of-file indicator is set for
the stream, even if data is available on the underlying file.

Apparently, POSIX aligns with the C standard here; System V tradition is
not to check the end-of-file indicator here. Both
src/lib/libc/stdio/refill.c (__srefill()) and Solaris fgetc(3) manpage
agree about this.

-- 
Jilles Tjoelker
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:38 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped