Mail Archives: cygwin/1999/02/17/21:46:43
> From: Corinna Vinschen <corinna DOT vinschen AT cityweb DOT 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 AT sourceware DOT cygnus DOT com
- Raw text -