This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project. See the Cygwin home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

Christopher Faylor wrote:
> 
> On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
> >
> >Here is the "Microsoft VC++ Run-Time Library Reference" quote:
> >
> >For streams opened in text mode, fseek has limited use, because
> >carriage return-linefeed translations can cause fseek to produce
> >unexpected results.  The only fseek operations guaranteed to work on
> >streams opened in text mode are:
> >
> >* Seeking with an offset of 0 relative to any of the origin values.
> >
> >* Seeking from the beginning of the file with an offset value returned
> >from a call to ftell.
> >
> >Also in text mode, CTRL+Z is interpreted as an end-of-file character
> >[...]

This is the _documentation_ of M$. In fact their code doesn't do the right
thing! As the ftell of newlib, it works without special calls of the
underlying OS, only calls to `_lseek()' are performed.  The only difference
between M$ and newlib is, that M$ performs additional counting of \n in
case of text file processing. It's done in the already translated buffer,
so the result is crap, as in newlib. Only their hit count is better.

> >Based on the documentation then I'll have to agree that your programs
> >isn't behaving as the documentation states that it should.  But, which
> >is wrong, fseek or ftell?
> 
> This does sound like a bug.  We'll try to look into this, time permitting.
> 
> If anyone else wants to take a stab at this (Corinna?) I'd be very grateful.

We have three possible choices:

1st: We are not performing the same errors as M$. We do our own, so we let
     it as it is.

2nd: M$-compatible errors, so we let ftell count \n, too. This would result
     in more often correct telling.

3rd: The full stdio code in newlib has to be changed. The buffer is used
     anyway in binary mode, every call has to use new counting and
     translation methods than the current one.
     Because this has to be done _very_ cautious, it's a long time change.

For the near future, I would prefer the second choice. Other opinions?

Regards,
Corinna


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com