[uClibc]fseek(3) idempotency

Matt Kraai kraai at alumni.carnegiemellon.edu
Tue Sep 25 09:05:55 UTC 2001


On Mon, Sep 24, 2001 at 04:55:29PM -0600, Erik Andersen wrote:
> On Mon Sep 24, 2001 at 04:50:47PM -0600, Matt Kraai wrote:
> > On Mon, Sep 24, 2001 at 04:45:11PM -0600, Erik Andersen wrote:
> > > Pulling out my copy of Posix/IEEE 1003.1b-1993, and it seems to agree
> > > with SuS2:
> > > 
> > > Some devices are incapable of seeking.  The value of the file offset associated
> > > with such a device is undefined.  The behavior of the lseek() function on such
> > > devices is implementation defined.
> > > 
> > > ...Otherwise, it shall return a value of ((off_t)-1), shall set errno to
> > > indicate the error, and the file offset shall remain unchanged by this function
> > > call.
> > 
> > So if you don't know a priori that a file is not a pipe, you can't
> > call [fl]seek on it?  This is retarded.
> 
> Nobody ever accused the standards folks of intelligence. :)
> Since uClibc is already Linux specific, I agree with Michael,
> we can safely rely on doing whatever glibc does in this case.
> What does Manuel's is_seekable do on pipes when compiled with
> glibc?

Since is_seekable only calls lseek(), it shouldn't matter what C
library you are using (unless fileno does something quite weird).

That said, I think we should fix fseek() to behave sanely.
The code in question works fine with glibc, and it makes a lot
more sense than forcing people to rely on lseek() to determine
whether seeking is supported (since its behavior is also
implementation defined).

Matt





More information about the uClibc mailing list