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

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

On Tue, Nov 2, 2021 at 11:39 AM Martin Husemann <martin%duskware.de@localhost> wrote:
>
> On Tue, Nov 02, 2021 at 10:53:55AM -0700, Carlo Arenas wrote:
> > Note that the failure in this case can be "fixed" by instead calling
> > lseek directly, removing the buffer or skipping this early return in
> > src/lib/libc/stdio/fseeko.c (lines 210 to 228), and that I am showing
> > below (might be mangled by copy and paste):
>
> I am not sure how you conclude this would violate Posix or the C
> standard. The behaviour inside the single program is correct, and I
> don't see any guarantees about shared files and current file position
> usage when using buffered stdio - but maybe I am overlooking something.

in that paragraph, I wasn't arguing about POSIX or C compatibility,
but the fact that the implementation behaves differently because of
the size of the buffer as shown by (using a sufficiently large input)
:

  $ head -2 <f.in
  1
  2
  $ (head -1 && head -1)<f.in
  1
  499

agree there is nothing in POSIX that should warrant the behaviour when
sharing a file AFAIK, even if it is obviously useful and some
implementations seem to allow it, but it doesn't forbid it either and
as it is shown above, it is already "supported" in NetBSD but it does
it in a way that differs with Windows/Linux/macOS/Solaris.

Carlo