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
