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

[Carlo Arenas <carenas%gmail.com@localhost>]

Greetings,

while troubleshooting a test failure for pcre2[0] in OpenBSD, tracked
down the problem to code that was inherited from NetBSD for their
fseek implementation in libc.

it can be worked around by calling lseek directly or by removing the
buffer, which would seem not to be updated if the seek is short enough
to be done directly in the buffer.

pcre2grep implements an -m flag that can be used to tell it a maximum
number of matches, after which it will exit; but needs to keep a state
of the last position of the stream that was processed, so that the
process could be resumed.

the following works in Windows/Linux/macOS :

  $ printf "1\n2\n3\n" > i && ( head -1; head -1; cat ) < i && rm -f i
1
2
3

but only works in recent NetBSD if STDBUF0=U is set (which is not
available in OpenBSD or other derivatives that are also affected (ex:
AIX))

is this a bug (it would seem to contradict ANSI C, and yes I tried
`fflush(stdin)` and didn't help) but the only way I found in the code
was to skip the optimization and call lseek, which obviously would be
detrimental performance wise, and obviously code hasn't changed in
decades.

Carlo

[0] https://github.com/PhilipHazel/pcre2/issues/10
[1] https://gist.github.com/carenas/7c13147ef10365bec2595c9e87102ae7