Re: is this a bug in glibc or readpst?

[Florian Weimer <fweimer@redhat.com>]

* Paul Wise via Libc-help:

> Looking at the stack traces, the _IO_SYNC call introduced in the commit
> 0b727ed4d that I identified as triggering the readpst bug is definitely
> the source of the lseek call.
>
>    lseek(3, -2138, SEEK_CUR)               = 268198
>     > /lib/x86_64-linux-gnu/libc.so.6(lseek64+0x7) [0xf81b7]
>     > /lib/x86_64-linux-gnu/libc.so.6(_IO_file_sync+0x7e) [0x800ae]
>     > /lib/x86_64-linux-gnu/libc.so.6(freopen+0x8c) [0x7d95c]
>     > /usr/bin/readpst(pst_reopen+0x36) [0x102c6]
>     > /usr/bin/readpst(try_fork+0x88) [0x4398]
>     > /usr/bin/readpst(process+0x121) [0xa451]
>     > /usr/bin/readpst(main+0x555) [0x3cc5]
>     > /lib/x86_64-linux-gnu/libc.so.6(__libc_init_first+0x8a) [0x271ca]
>     > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x27285]
>     > /usr/bin/readpst(_start+0x21) [0x4061]
>
> Based on the same thing happening with fflush+fclose+fopen, I'm not
> entirely sure, but I think that this represents a POSIX compliance bug
> in readpst that was papered over by the earlier behaviour of glibc.

We could perhaps avoid the seek for read-only streams.  We are about to
close the stream anyway, so fflush does not have any useful effect
anyway.  Not sure what others think if it is worth the complexity.  On
the other hand, preserving backwards compatibility here does not appear
to be too onerous.

Thanks,
Florian