From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. J. Farrell" To: corinna.vinschen@cityweb.de (Corinna Vinschen) Cc: cgf@cygnus.com, earnie_boyd@yahoo.com, kabal@ece.mcgill.ca, cygwin@sourceware.cygnus.com Subject: Re: Cygwin B20 - fseek under gcc fails to reposition on text files Date: Wed, 17 Feb 1999 13:46:00 -0000 Message-id: <199902172144.NAA02663@aleph.ssd.hal.com> In-reply-to: < 36CA92B5.844635AA@cityweb.de > from "Corinna Vinschen" at Feb 17, 99 10:58:13 am References: <36CA92B5.844635AA@cityweb.de> X-SW-Source: 1999-02/msg00572.html > From: Corinna Vinschen > > 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 shall be zero, or shall be a value returned by an earlier call to the function on the same stream and shall be . 4.9.9.4 long int ftell(FILE *stream) The function obtains the current value of the file position indicator for the stream pointed to by . For a text stream, its file position indicator contains unspecified information, usable by the function for returning the file position indicator for the stream to its position at the time of the 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. J. Farrell" To: corinna.vinschen@cityweb.de (Corinna Vinschen) Cc: cgf@cygnus.com, earnie_boyd@yahoo.com, kabal@ece.mcgill.ca, cygwin@sourceware.cygnus.com Subject: Re: Cygwin B20 - fseek under gcc fails to reposition on text files Date: Sun, 28 Feb 1999 23:02:00 -0000 Message-ID: <199902172144.NAA02663@aleph.ssd.hal.com> References: <36CA92B5.844635AA@cityweb.de> X-SW-Source: 1999-02n/msg00565.html Message-ID: <19990228230200.UOBmAv8gaii-2TFzlB062BAp8qIZjMXZhhO-AtK9vMc@z> > From: Corinna Vinschen > > 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 shall be zero, or shall be a value returned by an earlier call to the function on the same stream and shall be . 4.9.9.4 long int ftell(FILE *stream) The function obtains the current value of the file position indicator for the stream pointed to by . For a text stream, its file position indicator contains unspecified information, usable by the function for returning the file position indicator for the stream to its position at the time of the 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