Re: Buglet in fseek?

[Jeff Johnston <jjohnstn at redhat dot com>]

Corinna Vinschen wrote:
> On Feb 17 16:35, Jeff Johnston wrote:
>
> > I should haved clarified that the new fflush logic is only for read-only 
> > files; writable files do not have the fflush/fseek problem cited. 
> > Resetting the saved position is akin to setting it to -1 (an invalid 
> > value).  The FILE struct would have to be altered to add the new area to 
> > save the offset.
>
>
> What if we could just skip the fseek buffer optimization entirely using
> a compile time flag.
>
> The buffer optimization in fseek results in a non-POSIX behaviour and
> in theory, a target should actively choose the optimization in favor
> of the POSIX-compliance, shouldn't it?

It's not non-POSIX.  POSIX acknowledges the buffer optimization as 
valuable and it only is removed after the flush.

In the rationale and notes section:

"The fseek() function must operate as specified to make the case where 
seeking is being done work.  The key requirement is to avoid an 
optimization such that an fseek() would not result in an lseek() if the 
fseek() pointed within the current buffer.  This optimization is 
valuable in general, so it is only required after an fflush()."

Regarding your other note, we could make my initial solution simpler. 
fflush() on a read-only stream sets the _SNPT flag on and fseek() clears 
it appropriately after doing the lseek.  This solves the problem and 
doesn't care about what is done in-between.  If you fflush() a read-only 
stream, then the next fseek()/rewind() you do will be unoptimized.  I 
think that is fair.

-- Jeff J.