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

["J. J. Farrell" <jjf@bcs.org.uk>]

> From: Corinna Vinschen <corinna.vinschen@cityweb.de>
> 
> 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.
> 
> 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?

This isn't just a question of compatibility with MS, it's one of
conformance to Standard C - we should aim to get it right, in the
long term at least, whether we like it or not!

Here are a couple of extracts from C89 which describe how this
lot should work on text streams - it's perhaps safer to base an
implementation on what comes from the horse's mouth rather than
what MS's documentation says, though MS looks basically OK in
this case:

   4.9.9.2  int fseek(FILE *stream, long int offset, int whence)

   For a text stream, either <offset> shall be zero, or <offset>
   shall be a value returned by an earlier call to the <ftell>
   function on the same stream and <whence> shall be <SEEK_SET>.


   4.9.9.4  long int ftell(FILE *stream)

   The <ftell> function obtains the current value of the file
   position indicator for the stream pointed to by <stream>. 
   For a text stream, its file position indicator contains
   unspecified information, usable by the <fseek> function for
   returning the file position indicator for the stream to its
   position at the time of the <ftell> call; the difference
   between two such return values is not necessarily a meaningful
   measure of the number of characters written or read.

Do we do fgetpos/fsetpos right for both binary and text? The
definition of ftell/fseek for text is essentially the same as
fgetpos/fsetpos for both types - so I would guess there's either
a problem with fgetpos/fsetpos as well, or we could pinch
something from it for the ftell/fseek text case.


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