Re: Buglet in fseek?

[Corinna Vinschen <vinschen at redhat dot com>]

On Feb 17 16:17, Jeff Johnston wrote:
> Corinna Vinschen wrote:
> >Hi,
> >
> >while investigating a problem with top(1) on Cygwin, I came across this
> >description of fseek(3) in SUSv3:
> >
> >http://www.opengroup.org/onlinepubs/009695399/functions/fseek.html
> >
> >Quote:
> >
> >"[CX] If the most recent operation, other than ftell(), on a given
> > stream is fflush(), the file offset in the underlying open file
> > description shall be adjusted to reflect the location specified by
> > fseek()."
> >[...]
> >Would it be a problem to implement the above quoted behaviour in newlib?
> 
> I have no objection to it; it is also mentioned in the POSIX spec.  It 
> will be a little tricky to add to the current logic.
> 
> There are no spots left for flags in the _flags field of a FILE struct, 
> however, there is already a flag in place (_SNPT) which tells fseek not 
> to use the buffer optimization.  At present, the flag never gets reset 
> anywhere.
> 
> One possible solution might be to have fflush set the _SNPT flag as well 
> as saving the offset of the file (including read buffer position, 
> ignoring ungetc).  When a seek occurs, if dealing with a read-only file 
> with _SNPT flag set on and saved position != -1, a check is made 
> regarding the current position.  If the true position differs from the 
> saved position, then a read has occurred and we are not restricted to 
> performing the lseek.  In that case, we simply reset the _SNPT flag and 
> do the regular logic.  Otherwise, we allow the "goto dumb" logic to 
> occur and we reset the _SNPT flag and saved position if appropriate.
> 
> What do you thin?  Have I missed anything?  Typical read-only file usage 
> won't be interfered with.  There won't be any performance penalty added 
> to reads/etc..

Sounds good, but I'm not sure if that's exactly correct behaviour.
Taking the above quote from SUSv3 literally, only stream operations
should influence the behaviour:

  "If the most recent operation [...] on a given *stream* [...]"

So, literally, using fread or getc or even freopen should result
in resetting the _SNPT flag, while, for instance

  read (fileno (stream), ...)

is not a stream operation and so should not influence the described
behaviour.  Or is that taking the quote too literally?

And then, what about operations on streams which don't move the
current file position, like, for instance, freopen, clearerr, setbuf?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat