This is the mail archive of the newlib@sources.redhat.com mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 1.3.3-2: fseek fails on multiples of 1024 (binary mode)


Christopher Faylor wrote:
> 
> On Tue, Oct 23, 2001 at 11:07:03PM -0400, Christopher Faylor wrote:
> >Is this fixed in more recent BSD code, perhaps?  Or has the code diverged too far
> >for this to be useful?
> 
> Answering my own question: No, the code hasn't changed that much and
> there seems to be one minor change in it, which is below.
> 
> Is it my imagination or does this actually fix the problem?  I haven't
> studied the code that much but, from context, the patch makes sense.
> 
> cgf
> 
> Index: libc/stdio/fseek.c
> ===================================================================
> RCS file: /cvs/uberbaum/newlib/libc/stdio/fseek.c,v
> retrieving revision 1.1.1.1
> diff -p -r1.1.1.1 fseek.c
> *** fseek.c     2000/02/17 19:39:47     1.1.1.1
> --- fseek.c     2001/10/24 03:20:13
> *************** fseek (fp, offset, whence)
> *** 278,283 ****
> --- 278,284 ----
>     if ((*seekfn) (fp->_cookie, curoff, SEEK_SET) == POS_ERR)
>       goto dumb;
>     fp->_r = 0;
> +   fp->_p = fp->_bf._base;
>     if (HASUB (fp))
>       FREEUB (fp);
>     fp->_flags &= ~__SEOF;

Chris, where did you get this diff from ?! :) I think it's indeed the
thing which fixes the problem - now as I look at the FreeBSD's fseek
it has this one too. The previous time i looked at it, I've focused on
the code snippet i pasted in my previous mail.

Ok, let's do some math :)

curoff = 2048;			// After the first fseek which puts the file pointer
				// to the end of the file.

curoff -= fp->_r;		// fp->_r is zeroed on each seek out of the
				// buffered region: 2048 - 0 = 2048

n = fp->_p - fp->_bf.base;	// Number of bytes read becomes zero since
				// fp->_p is set to fp->_bf.base after each
				// seek out of the buffered region.

curoff -= n;			// Finally determines last file position where
				// possibly there was a read. Since there is no
                                // read however we are stuck at the
position
                                // where last fseek occured: 2048 - 0 =
2048

n += fp->_r;			// Determines the upper limit of the internal buffer
				// 0 + 0 = 0

target >= curoff && target < curoff + n	// 1024 >= 2048 && 1024 < 2048 +
0
					// We seek somewhere else an no
					// need to adjust any pointers :)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]