[uClibc]fseek(3) idempotency

[Manuel Novoa III]

Matt,

On Mon, Sep 24, 2001 at 10:35:03AM -0600, Matt Kraai wrote:
> On Mon, Sep 24, 2001 at 10:03:03AM -0600, Manuel Novoa III wrote:
> > On Mon, Sep 24, 2001 at 09:25:31AM -0600, Matt Kraai wrote:
> > > The uClibc fseek(3) implementation clears the readahead buffer
> > > before calling lseek(2).  If lseek(2) fails (e.g., it is called on
> > > a pipe), the position is now off.
> > 
> > In my interpretation of the standards, if fseek() fails the error
> > indicator for the stream is set and the associated file offset is
> > undefined.  What's the problem?
> > 
> > >                 The following patch only resets
> > > the readahead buffer if the lseek(2) call succeeds.
> > 
> > It looks to me like you're trying to deal with an application bug
> > by introducing implementation-defined behavior to uClibc.
> 
> According to SUSv2,
> 
> 	The behaviour of fseek() on devices which are incapable of
> 	seeking is implementation-dependent.
> 
> How can you determine if a device supports seeking?

Something like the following _might_ work.  It needs testing though.

int is_seekable(FILE *fp)
{
	/* Hope that the OS always returns an error for pipes or fifos */
	/* even when the offset is 0. */
	return ( lseek(fileno(fp),0,SEEK_CUR) >= 0 );
}

Manuel