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

[RVP <rvp%SDF.ORG@localhost>]

On Wed, 3 Nov 2021, Carlo Arenas wrote:

> 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.

Don't bother; that first patch only handles the non-seek case like
the test code in your initial mail. I have to fix-up the code to
take care of explicit seeks, too.

> 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,

Yes, that case is not handled in the patch...


> 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,

That's an ftell() (or similar) and shouldn't interfere with subsequent
fseek()s.

> 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]

If you read closely, you'll see that those requirements are marked as
extensions and so not necessary for (strict) compliance. In fact, the
fflush() RATIONALE says:

     Data buffered by the system may make determining the validity
     of the position of the current file descriptor impractical.
     Thus, enforcing the repositioning of the file descriptor after
     fflush() on streams open for read() is not mandated by
     POSIX.1-2017.

but, fflush() causing an underlying seek seems useful. I'll see what
I can do this weekend.

-RVP