tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: possible bug in fseek of buffered files shared between processes (example uses stdin)

On Tue, Nov 2, 2021 at 4:54 PM Carlo Arenas <> wrote:
> On Tue, Nov 2, 2021 at 3:17 PM RVP <> wrote:
> >
> > Carlo, can you see if that works with your use-case?
> I only have a slow OpenBSD VM with current to test, so I am building a
> port of your patch there (which seems will take several more hours to
> build), I kept the "cheating" part there though, so not sure how much
> useful my answer would be, but I expect it to work.

but it didn't work (even if it seems to be a step in the right
direction); not sure if it was me who messed it up though, but
building another iteration takes too long to know; will try with
NetBSD current next.

It did seem to help with `head -1` though, but even if their
implementation uses stdio, it is doing character by character reads
and no fseek, so the added code in fclose does the right thing and
keeps the not consumed part of the stream available for the next

in my testcase[1] (and pcre2grep), we are using the buffer whole and
need to fseek to get it to the right place if the read was overshot,
but something else seems to be doing an lseek(0, 0, SEEK_CUR) at the
end of the buffer read, and that conflicts with the new fclose code,
setting the position to the wrong place for the next process, as a
result (even if set correctly by doing an lseek through the

an alternative implementation, might use to its advantage the fact
that at close time the streams should be flushed and do the necessary
seek there as required by fflush[2] in POSIX (seems that at least
since SUSv3, an fflush(stdin) is a valid operation and should update
the position of the underlying file)[3]



Home | Main Index | Thread Index | Old Index