Project

General

Profile

Bug #6503

fseek() seems to be documented to do an implicit fflush()

Added by Richard PALO almost 5 years ago. Updated almost 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
lib - userland libraries
Start date:
2015-12-09
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

As indicated on the general illumos list,
the attached test file demonstrates an anomaly that seeking doesn't
seem to automatically flush buffers in buffered file opened r/w.

This is a crude reproduction of a situation where the latest mercurial has issues with
certain repositories as reported https://bz.mercurial-scm.org/show_bug.cgi?id=4943


Files

tseek.c (1.46 KB) tseek.c test program Richard PALO, 2015-12-09 07:00 AM

History

#1

Updated by Richard PALO almost 5 years ago

more or less an equivalent approach:

http://nxr.netbsd.org/xref/src/lib/libc/stdio/fseeko.c
http://src.illumos.org/source/xref/freebsd-head/lib/libc/stdio/fseek.c

both flush (if deemed necessary after some checks)

#2

Updated by Richard PALO almost 5 years ago

Is it possible there is a test in the POSIX conformance test suite for
this particular case of fseek in a file stream opened r/w + ?

http://en.cppreference.com/w/c/io/fseek
from notes

POSIX also requires that fseek first performs fflush if there are any unwritten data (but whether the shift state is restored is implementation-defined).

Also available in: Atom PDF