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

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

[Earnie Boyd]

You need to read the docs about "text mode processing".  This is
exactly the expected behavior.  If you're going to use these functions
then you must process in binary mode.

Regards,
Earnie.

---Peter Kabal <kabal@ECE.McGill.CA> wrote:
>
> Consider a text file (CR/LF line endings).  Read a line, save the
> current position, seek to end-of-file, seek to the saved position,
> read a line.  The second read does not return the second line of
> the file.
> 
> A shell script which tests the problem is included below:
> ---------------------------------------------------------------------
> #!/bin/sh
> #
> # Test fseek bug
> # On Cygwin 20.1, a file is not correctly repositioned after seeking
to the
> # end-of-file on a text file (CR/LF line endings).
> 
> cat > tfrepos.c << EoF
> #include <stdio.h>
> int main (int argc, char *argv[])
> {
>   FILE *fp;
>   long int pos, size;
>   char line[200];
>   char *p;
> 
>   fp = fopen (argv[1], "r");
>   p = fgets (line, 200, fp);
>   printf (" Line: %s", p);
> 
>   pos = ftell (fp);
>   fseek (fp, 0L, SEEK_END);
>   fseek (fp, pos, SEEK_SET);
> 
>   p = fgets (line, 200, fp);
>   printf (" Line: %s", p);
> 
>   return 0;
> }
> EoF
> 
> # Run the test program with the c-program as input
> gcc tfrepos.c -o tfrepos
> ./tfrepos tfrepos.c
> 
> # Clean up
> rm -f tfrepos tfrepos.c
> ---------------------------------------------------------------------
> 
> Peter Kabal  kabal@ECE.McGill.CA
> Dept. Electrical & Computer Eng.
> McGill University 
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

[Earnie Boyd]

You need to read the docs about "text mode processing".  This is
exactly the expected behavior.  If you're going to use these functions
then you must process in binary mode.

Regards,
Earnie.

---Peter Kabal <kabal@ECE.McGill.CA> wrote:
>
> Consider a text file (CR/LF line endings).  Read a line, save the
> current position, seek to end-of-file, seek to the saved position,
> read a line.  The second read does not return the second line of
> the file.
> 
> A shell script which tests the problem is included below:
> ---------------------------------------------------------------------
> #!/bin/sh
> #
> # Test fseek bug
> # On Cygwin 20.1, a file is not correctly repositioned after seeking
to the
> # end-of-file on a text file (CR/LF line endings).
> 
> cat > tfrepos.c << EoF
> #include <stdio.h>
> int main (int argc, char *argv[])
> {
>   FILE *fp;
>   long int pos, size;
>   char line[200];
>   char *p;
> 
>   fp = fopen (argv[1], "r");
>   p = fgets (line, 200, fp);
>   printf (" Line: %s", p);
> 
>   pos = ftell (fp);
>   fseek (fp, 0L, SEEK_END);
>   fseek (fp, pos, SEEK_SET);
> 
>   p = fgets (line, 200, fp);
>   printf (" Line: %s", p);
> 
>   return 0;
> }
> EoF
> 
> # Run the test program with the c-program as input
> gcc tfrepos.c -o tfrepos
> ./tfrepos tfrepos.c
> 
> # Clean up
> rm -f tfrepos tfrepos.c
> ---------------------------------------------------------------------
> 
> Peter Kabal  kabal@ECE.McGill.CA
> Dept. Electrical & Computer Eng.
> McGill University 
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

[Earnie Boyd]

---Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:
>
> I don't want to be boring, but shouldn't we return
> to the _subject_ instead of discussing the ability
> (or it's absence) to understand contributing?

The contribution discussion is under a different thread.

> 
> You still know the subject? Three choices? Opinions?

In the short-term option 2 in the long-term option 3.  I believe that
any fix that would allow this to work most of the time with the next
release would be beneficial.  However, this should not be a permanent
solution to the problem and a more long term correct method should be
applied.


> 
> And moreover:
> Isn't this a theme for cygwin-developers???

Probably, but it was brought up here so any resolution created on the
cygwin-developers needs to be posted here.
==
-                        \\||//
-------------------o0O0--Earnie--0O0o-------------------
--                earnie_boyd@yahoo.com               --
-- http://www.freeyellow.com/members5/gw32/index.html --
----------------------ooo0O--O0ooo----------------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

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

[Earnie Boyd]

---Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:
>
> I don't want to be boring, but shouldn't we return
> to the _subject_ instead of discussing the ability
> (or it's absence) to understand contributing?

The contribution discussion is under a different thread.

> 
> You still know the subject? Three choices? Opinions?

In the short-term option 2 in the long-term option 3.  I believe that
any fix that would allow this to work most of the time with the next
release would be beneficial.  However, this should not be a permanent
solution to the problem and a more long term correct method should be
applied.


> 
> And moreover:
> Isn't this a theme for cygwin-developers???

Probably, but it was brought up here so any resolution created on the
cygwin-developers needs to be posted here.
==
-                        \\||//
-------------------o0O0--Earnie--0O0o-------------------
--                earnie_boyd@yahoo.com               --
-- http://www.freeyellow.com/members5/gw32/index.html --
----------------------ooo0O--O0ooo----------------------

PS: Newbie's, you should visit my page.
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com


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

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

[setera]

>Currently, Corinna, Mumit, and a couple of other people are the only
>outside contributers to the project.  Everyone else seems to be in
>"Cygwin doesn't work the way I think it should when I run program X.
>Here's the error message." mode.
>
>I'm collecting the error messages and hope to investigate problems but
>the reality is that this is a volunteer effort for DJ and me.  Our
>real jobs don't offer much time for tracking down net problems.

Chris,

I can certainly understand your frustrations.  In my GIMP work, I've had a
heck of a time with some hanging problems which I've reported to you.  I
report them to you and DJ not because I *expect* you to jump and fix them,
but because I am clueless on how to fix them myself.  I *have* downloaded
the source code and *have* attempted to understand the infrastructure
enough to solve the problems.  In my case at least, if there were more
documentation on the internals of the winsup code, I might be able to solve
some problems on my own.  Unfortunately, I think with the exception of a
few people (you, DJ, Sergey, etc) most do not have a good enough
understanding of the internals of winsup to really be able to help out.  On
the other hand, I try not to complain about things either.

Anyway, just another person's perspective.

Craig


Craig Setera
AS/400 Enterprise Java Development
IBM Rochester
setera@us.ibm.com
(507) 253-3387 - Tie: 553-3387




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

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

[Christopher Faylor]

On Fri, Feb 19, 1999 at 09:00:04AM -0600, setera@us.ibm.com wrote:
>
>>Currently, Corinna, Mumit, and a couple of other people are the only
>>outside contributers to the project.  Everyone else seems to be in
>>"Cygwin doesn't work the way I think it should when I run program X.
>>Here's the error message." mode.
>>
>>I'm collecting the error messages and hope to investigate problems but
>>the reality is that this is a volunteer effort for DJ and me.  Our
>>real jobs don't offer much time for tracking down net problems.
>
>I can certainly understand your frustrations.  In my GIMP work, I've had a
>heck of a time with some hanging problems which I've reported to you.  I
>report them to you and DJ not because I *expect* you to jump and fix them,
>but because I am clueless on how to fix them myself.  I *have* downloaded
>the source code and *have* attempted to understand the infrastructure
>enough to solve the problems.  In my case at least, if there were more
>documentation on the internals of the winsup code, I might be able to solve
>some problems on my own.  Unfortunately, I think with the exception of a
>few people (you, DJ, Sergey, etc) most do not have a good enough
>understanding of the internals of winsup to really be able to help out.  On
>the other hand, I try not to complain about things either.

It is not impossible to figure out how things work with cygwin.  I know
because I did it.  You may not remember, or maybe you weren't around,
but I started out as a net contributer before Cygnus hired me.

Cygwin is certainly considerably less complicated than Linux ever was
and people have managed to make considerable contributions to the Linux
kernel.

As I said, if you can't contribute, I certainly understand but, it's a fact of
life that things are not going to change quickly with 2.5 people working on the
project, especially when most of those people have day jobs.

cgf

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

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

[Corinna Vinschen]

I don't want to be boring, but shouldn't we return
to the _subject_ instead of discussing the ability
(or it's absence) to understand contributing?

You still know the subject? Three choices? Opinions?

And moreover:
Isn't this a theme for cygwin-developers???

Corinna



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

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

[Corinna Vinschen]

I don't want to be boring, but shouldn't we return
to the _subject_ instead of discussing the ability
(or it's absence) to understand contributing?

You still know the subject? Three choices? Opinions?

And moreover:
Isn't this a theme for cygwin-developers???

Corinna



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

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

[Christopher Faylor]

On Fri, Feb 19, 1999 at 09:00:04AM -0600, setera@us.ibm.com wrote:
>
>>Currently, Corinna, Mumit, and a couple of other people are the only
>>outside contributers to the project.  Everyone else seems to be in
>>"Cygwin doesn't work the way I think it should when I run program X.
>>Here's the error message." mode.
>>
>>I'm collecting the error messages and hope to investigate problems but
>>the reality is that this is a volunteer effort for DJ and me.  Our
>>real jobs don't offer much time for tracking down net problems.
>
>I can certainly understand your frustrations.  In my GIMP work, I've had a
>heck of a time with some hanging problems which I've reported to you.  I
>report them to you and DJ not because I *expect* you to jump and fix them,
>but because I am clueless on how to fix them myself.  I *have* downloaded
>the source code and *have* attempted to understand the infrastructure
>enough to solve the problems.  In my case at least, if there were more
>documentation on the internals of the winsup code, I might be able to solve
>some problems on my own.  Unfortunately, I think with the exception of a
>few people (you, DJ, Sergey, etc) most do not have a good enough
>understanding of the internals of winsup to really be able to help out.  On
>the other hand, I try not to complain about things either.

It is not impossible to figure out how things work with cygwin.  I know
because I did it.  You may not remember, or maybe you weren't around,
but I started out as a net contributer before Cygnus hired me.

Cygwin is certainly considerably less complicated than Linux ever was
and people have managed to make considerable contributions to the Linux
kernel.

As I said, if you can't contribute, I certainly understand but, it's a fact of
life that things are not going to change quickly with 2.5 people working on the
project, especially when most of those people have day jobs.

cgf

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

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

[setera]

>Currently, Corinna, Mumit, and a couple of other people are the only
>outside contributers to the project.  Everyone else seems to be in
>"Cygwin doesn't work the way I think it should when I run program X.
>Here's the error message." mode.
>
>I'm collecting the error messages and hope to investigate problems but
>the reality is that this is a volunteer effort for DJ and me.  Our
>real jobs don't offer much time for tracking down net problems.

Chris,

I can certainly understand your frustrations.  In my GIMP work, I've had a
heck of a time with some hanging problems which I've reported to you.  I
report them to you and DJ not because I *expect* you to jump and fix them,
but because I am clueless on how to fix them myself.  I *have* downloaded
the source code and *have* attempted to understand the infrastructure
enough to solve the problems.  In my case at least, if there were more
documentation on the internals of the winsup code, I might be able to solve
some problems on my own.  Unfortunately, I think with the exception of a
few people (you, DJ, Sergey, etc) most do not have a good enough
understanding of the internals of winsup to really be able to help out.  On
the other hand, I try not to complain about things either.

Anyway, just another person's perspective.

Craig


Craig Setera
AS/400 Enterprise Java Development
IBM Rochester
setera@us.ibm.com
(507) 253-3387 - Tie: 553-3387




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

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

[Earnie Boyd]

Ok I appoligize.

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
on input.  In files opened for reading/writing, fopen and all related
routines check for a CTRL+Z at the end of the file and remove it if
possible.  This is done because using fseek and ftell to move within
an file that ends in CTRL+Z may cause fseek to behave improperly near
the end of the file.

---

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?

Sorry for speaking out of line,
Earnie.

---Peter Kabal <kabal@ece.mcgill.ca> wrote:
>
> I did.  I quote from Harbison and Steele, Fourth edition, p 353.
> 
> "The following, more limited set of calls is permitted on text streams
> by ISO C:
> 
> fseek (stream, 0L, SEEK_SET)
> fseek (stream, 0L, SEEK_CUR)
> fseek (stream, 0L, SEEK_END)
> fseek (stream, 0L, ftell_pos, SEEK_SET)  at a position returned by a
>     previous call to ftell for stream.
> "
> 
> I <did> read the docs about "text mode processing"!  Your comment was
> unwarranted and warrants an apology.
> 
> > -----Original Message-----
> > From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> > Sent: February 16, 1999 8:28 AM
> > To: kabal@ece.mcgill.ca
> > Cc: cygwin users
> > Subject: Re: Cygwin B20 - fseek under gcc fails to reposition on
text
> > files
> > 
> > 
> > 
> > You need to read the docs about "text mode processing".  This is
> > exactly the expected behavior.  If you're going to use these
functions
> > then you must process in binary mode.
> > 
> > Regards,
> > Earnie.
> > 
> > ---Peter Kabal <kabal@ECE.McGill.CA> wrote:
> > >
> > > Consider a text file (CR/LF line endings).  Read a line, save the
> > > current position, seek to end-of-file, seek to the saved position,
> > > read a line.  The second read does not return the second line of
> > > the file.
> > > 
> > > A shell script which tests the problem is included below:
> > >
---------------------------------------------------------------------
> > > #!/bin/sh
> > > #
> > > # Test fseek bug
> > > # On Cygwin 20.1, a file is not correctly repositioned after
seeking
> > to the
> > > # end-of-file on a text file (CR/LF line endings).
> > > 
> > > cat > tfrepos.c << EoF
> > > #include <stdio.h>
> > > int main (int argc, char *argv[])
> > > {
> > >   FILE *fp;
> > >   long int pos, size;
> > >   char line[200];
> > >   char *p;
> > > 
> > >   fp = fopen (argv[1], "r");
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   pos = ftell (fp);
> > >   fseek (fp, 0L, SEEK_END);
> > >   fseek (fp, pos, SEEK_SET);
> > > 
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   return 0;
> > > }
> > > EoF
> > > 
> > > # Run the test program with the c-program as input
> > > gcc tfrepos.c -o tfrepos
> > > ./tfrepos tfrepos.c
> > > 
> > > # Clean up
> > > rm -f tfrepos tfrepos.c
> > >
---------------------------------------------------------------------
> > > 
> > > Peter Kabal  kabal@ECE.McGill.CA
> > > Dept. Electrical & Computer Eng.
> > > McGill University 
> > > 
> > 
> > _________________________________________________________
> > DO YOU YAHOO!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> > 
> > 
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

[Christopher Faylor]

On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
>
>Ok I appoligize.
>
>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
>on input.  In files opened for reading/writing, fopen and all related
>routines check for a CTRL+Z at the end of the file and remove it if
>possible.  This is done because using fseek and ftell to move within
>an file that ends in CTRL+Z may cause fseek to behave improperly near
>the end of the file.
>
>---
>
>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?
>
>Sorry for speaking out of line,

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.

-chris

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

[DJ Delorie]

> >* Seeking with an offset of 0 relative to any of the origin values.

This means fseek(file, 0, SEEK_SET) or fseek(file, 0, SEEK_END).

> >* Seeking from the beginning of the file with an offset value returned
> >from a call to ftell.

This allows the library to read() through the file instead of seeking,
to compensage for CR/LF conversions.  If you seek from the end of the
file, these rules do not guarantee success.

The problems are usually in ftell(), since with buffered I/O it's
nearly impossible to determine what actual file position corresponds
to a character in the middle of a stdio buffer.  DJGPP could only
solve this problem by having stdio open *all* files as binary, and
managing the conversion after the buffering.

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

[DJ Delorie]

> >* Seeking with an offset of 0 relative to any of the origin values.

This means fseek(file, 0, SEEK_SET) or fseek(file, 0, SEEK_END).

> >* Seeking from the beginning of the file with an offset value returned
> >from a call to ftell.

This allows the library to read() through the file instead of seeking,
to compensage for CR/LF conversions.  If you seek from the end of the
file, these rules do not guarantee success.

The problems are usually in ftell(), since with buffered I/O it's
nearly impossible to determine what actual file position corresponds
to a character in the middle of a stdio buffer.  DJGPP could only
solve this problem by having stdio open *all* files as binary, and
managing the conversion after the buffering.

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

[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.

> >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

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

[DJ Delorie]

> 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.

FYI, DJGPP does it this way, and you're right, it was a big change.

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

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

[DJ Delorie]

> 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.

FYI, DJGPP does it this way, and you're right, it was a big change.

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

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

[J. J. Farrell]

> 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

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

[J. J. Farrell]

> 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

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

[Paul Sokolovsky]

Hello Corinna,

Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:

[]

CV> We have three possible choices:

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

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

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

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

    Let me support 3rd way, in rather flamy passages, however.

    So, for more than twenty years MS maintains myth about "special
format" of text files of their systems. It's hardly believable. Since
my old XT I quite nicely handled any text files - be they Unix \xa,
Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
"special" format of text files. Most tools available handled any type,
and conversion between formats was quite feasible. With win32, such
problems are ceased at all - I don't have no line endings problems, no
encoding problems, even that unicode seams to be here.

   And here we come to most interesting questions - that fact that MS
maintains aforementioned myth is not surprising, but that myth is
carefully maintained by outside crew too! Just listen to those GNUers
telling us that text files here are "special" and they must dirty
workaround that! Just see peoples advocating data stream corruption on
most basic system level!

   But what if stop that play and acknowledge that some guys have done
quite well and it's useless to try to not notice that. \r\n textfiles
should be handled properly where they belong - e.g. in textutils, but
never in core system, leading just to corruption.

   So, what I argue:

1. Text/binary file notion on most basic, POSIX level should be
   abandoned.
2. That has nothing to do with stdio level - since default accessors for
   that level are single-character oriented, it doesn't hurt much
   stuffing single test there.

(Note that this indeed DJ Delorie's idea as of DJGPP lib, pushed further
to exterminating textuality on POSIX level at all)

3. All stuff working with textfiles and using POSIX level either should
   be taught accept any line-endings or reimplented in stdio.

4. Until then, there're fromdos/todos filters.


   And finally, from where all this stuff might be originated - it may
be done whatever wanted, but if, when writing to console we get clobbered
output without carrage returns, it doesn't cost a cent. That's where
myth of win32 speciality breaks down - Win32 console, as any other
console in cooked mode (Linux, say) performs implicit cr after lf,
when there's no explicit.

   Just run following (tested only on Win95/Win95OSR2 to be honest):

--------
#include <windows.h>

char str[]="\nline1\nline2\nline3\n";

void main()
{
  DWORD dummy;
  WriteFile(STD_OUTPUT_HANDLE,str,sizeof(str)-1,&dummy,NULL);
  WriteFile(STD_ERROR_HANDLE,str,sizeof(str)-1,&dummy,NULL);
}
--------


CV> Regards,
CV> Corinna


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

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

[DJ Delorie]

>    And finally, from where all this stuff might be originated - it may
> be done whatever wanted, but if, when writing to console we get clobbered
> output without carrage returns, it doesn't cost a cent. That's where
> myth of win32 speciality breaks down - Win32 console, as any other
> console in cooked mode (Linux, say) performs implicit cr after lf,
> when there's no explicit.

To add fact to the myth, if you bring up such a file (\n without \r)
in notepad, it does not do the right thing - it very explicitly looks
for the CR/LF pair to mean a line ending, and no other ending will do.

Batch files also cannot have NL endings - they need CR/LF endings.

Of course, this really just means that the programmers were
short-sighted, but it's still a fact we must live with.

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

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

[Larry Hall]

At 01:07 PM 2/17/99 -0500, DJ Delorie wrote:
>Batch files also cannot have NL endings - they need CR/LF endings.

You sure about that?  In my binary mounted environment I tried:

D:\tmp>cat b.bat
echo hello

D:\tmp>b

D:\tmp>echo hello
hello

D:\tmp>od -h b.bat
0000000 6365 6f68 6820 6c65 6f6c 000a
0000013

D:\tmp>

Hm...


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02482-7797               http://www.rfk.com

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

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

[DJ Delorie]

> You sure about that?  In my binary mounted environment I tried:

Under Win95, try two lines:

	echo hi
	dir

I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.

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

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

[Larry Hall]

At 10:18 PM 2/17/99 -0500, DJ Delorie wrote:
>
>> You sure about that?  In my binary mounted environment I tried:
>
>Under Win95, try two lines:
>
>	echo hi
>	dir
>
>I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.
>

Ah, forgot about that!  I'm on NT!;-)


Larry

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

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

[Larry Hall]

At 10:18 PM 2/17/99 -0500, DJ Delorie wrote:
>
>> You sure about that?  In my binary mounted environment I tried:
>
>Under Win95, try two lines:
>
>	echo hi
>	dir
>
>I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.
>

Ah, forgot about that!  I'm on NT!;-)


Larry

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

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

[DJ Delorie]

> You sure about that?  In my binary mounted environment I tried:

Under Win95, try two lines:

	echo hi
	dir

I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.

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

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

[Larry Hall]

At 01:07 PM 2/17/99 -0500, DJ Delorie wrote:
>Batch files also cannot have NL endings - they need CR/LF endings.

You sure about that?  In my binary mounted environment I tried:

D:\tmp>cat b.bat
echo hello

D:\tmp>b

D:\tmp>echo hello
hello

D:\tmp>od -h b.bat
0000000 6365 6f68 6820 6c65 6f6c 000a
0000013

D:\tmp>

Hm...


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02482-7797               http://www.rfk.com

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

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

[DJ Delorie]

>    And finally, from where all this stuff might be originated - it may
> be done whatever wanted, but if, when writing to console we get clobbered
> output without carrage returns, it doesn't cost a cent. That's where
> myth of win32 speciality breaks down - Win32 console, as any other
> console in cooked mode (Linux, say) performs implicit cr after lf,
> when there's no explicit.

To add fact to the myth, if you bring up such a file (\n without \r)
in notepad, it does not do the right thing - it very explicitly looks
for the CR/LF pair to mean a line ending, and no other ending will do.

Batch files also cannot have NL endings - they need CR/LF endings.

Of course, this really just means that the programmers were
short-sighted, but it's still a fact we must live with.

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

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

[Corinna Vinschen]

Paul Sokolovsky wrote:
>     So, for more than twenty years MS maintains myth about "special
> format" of text files of their systems. It's hardly believable. Since
> my old XT I quite nicely handled any text files - be they Unix \xa,
> Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
> "special" format of text files. Most tools available handled any type,
> and conversion between formats was quite feasible. With win32, such
> problems are ceased at all - I don't have no line endings problems, no
> encoding problems, even that unicode seams to be here.

As a matter of fact: Peter's c example, which opens this thread, does
not work with VC++, if the newline is not \r\n. Look into the source
of M$-ftell(), it can't work.

The best way would be to throw away and ignore any newline with
more than one single character.

But let's get serious.

IMHO, above all text file processing should be done according to the
underlying OS and it's vendor, also if this is wretched.

The second choice has the advantage, to be easy to implement.

The third choice should be implemented, if s.o. has nothing important
to do.

Regards,
Corinna


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

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

[Paul Sokolovsky]

Hello Corinna,

Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:

>>     So, for more than twenty years MS maintains myth about "special
>> format" of text files of their systems. It's hardly believable. Since

CV> The best way would be to throw away and ignore any newline with
CV> more than one single character.

    Yes, and bad thing is that people came say, from Unix, and don't knowing
that here text files are special, but constantly getting binary file
corruptions when filtering gifs, piping gzips, etc. may think that way is
right ;-(

CV> But let's get serious.

CV> IMHO, above all text file processing should be done according to the
CV> underlying OS and it's vendor, also if this is wretched.

    Bad thing is that issue very minor. People might don't care what
line-endings text files have, they might don't care that there's
notepad and bat files. And when their favorite vi chokes on that \r at
the end (or beginning? ;-) ) of line they might teach him chop it -
after all, that's not notepad. But they might think that wrapping each
command piping binary files in shell script setting CYGWIN (having
spent some nice time trying to understand why their files are
corrupted and asking maillist why this bug) is too awkward.

   Of course, that far too imaganable picture, just like my previous
massage has, just like several years ago cygwin itself was only
imaganable. I don't believe that things enpictured by me will be, or
even should be, done to cygwin. I just wanted to hyperbolize it,
showing that changing itself is not an edge alternative, all
determained by ammount of changes, and there might be the golden mean,
exactly what you'll do. (That's just because I have a ho that Cygnus
guys quite conservative - I remember Christopher Faylor's hesitating
in cygwin-developer whether correcting bug won't break user (or
customer) code. Maybe you, Corinna, as leading contributor, and DJ, as
author of alternative approach, and working for Cygnus, have other
opinions).

   But there still that idea - there maybe niche that cygwin doesn't
fill - to be more unixish despite be less winnish.

CV> The second choice has the advantage, to be easy to implement.

CV> The third choice should be implemented, if s.o. has nothing important
CV> to do.

CV> Regards,
CV> Corinna

    Thanks for not taking previous text as profanity, that's was just rebellion
humoresqe, just forgot adding trailing disclaimer ;-)


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


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

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

[Christopher Faylor]

On Thu, Feb 18, 1999 at 06:38:46PM +0200, Paul Sokolovsky wrote:
>    Bad thing is that issue very minor. People might don't care what
>line-endings text files have, they might don't care that there's
>notepad and bat files. And when their favorite vi chokes on that \r at
>the end (or beginning? ;-) ) of line they might teach him chop it -
>after all, that's not notepad. But they might think that wrapping each
>command piping binary files in shell script setting CYGWIN (having
>spent some nice time trying to understand why their files are
>corrupted and asking maillist why this bug) is too awkward.

Actually, as far as pipes are concerned, they default to binmode
unless overridden by CYGWIN so this should not be an issue.

>   Of course, that far too imaganable picture, just like my previous
>massage has, just like several years ago cygwin itself was only
>imaganable. I don't believe that things enpictured by me will be, or
>even should be, done to cygwin. I just wanted to hyperbolize it,
>showing that changing itself is not an edge alternative, all
>determained by ammount of changes, and there might be the golden mean,
>exactly what you'll do. (That's just because I have a ho that Cygnus
>guys quite conservative - I remember Christopher Faylor's hesitating
>in cygwin-developer whether correcting bug won't break user (or
>customer) code. Maybe you, Corinna, as leading contributor, and DJ, as
>author of alternative approach, and working for Cygnus, have other
>opinions).

I have no idea what, specifically, you are referring to but it is
interesting that you find it "quite conservative" to consider caring
about breaking somebody's code.  You are probably referring to my
soliciting of opinions on the subject of breaking API compatibility
with a new cygwin DLL.  This was obviously a subject which deserved
careful consideration and it was something that I was willing to do.
In fact, it is something that *will* occur in a future release.

Regardless, if you look at the ChangeLog in the last year, you'll find
that I'm the author of a lot of radical changes in Cygwin.

I am not at all opposed to the idea of somebody fixing ftell/fseek
to work as Microsoft has documented them or as DJGPP has currently
implemented things.  I've written a stdio layer myself and I know
that this is not a trivial undertaking, though.  Certainly no
one at Cygnus has the time right now to undertake this.

Currently, Corinna, Mumit, and a couple of other people are the only
outside contributers to the project.  Everyone else seems to be in
"Cygwin doesn't work the way I think it should when I run program X.
Here's the error message." mode.

I'm collecting the error messages and hope to investigate problems but
the reality is that this is a volunteer effort for DJ and me.  Our
real jobs don't offer much time for tracking down net problems.

-chris

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

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

[Christopher Faylor]

On Thu, Feb 18, 1999 at 06:38:46PM +0200, Paul Sokolovsky wrote:
>    Bad thing is that issue very minor. People might don't care what
>line-endings text files have, they might don't care that there's
>notepad and bat files. And when their favorite vi chokes on that \r at
>the end (or beginning? ;-) ) of line they might teach him chop it -
>after all, that's not notepad. But they might think that wrapping each
>command piping binary files in shell script setting CYGWIN (having
>spent some nice time trying to understand why their files are
>corrupted and asking maillist why this bug) is too awkward.

Actually, as far as pipes are concerned, they default to binmode
unless overridden by CYGWIN so this should not be an issue.

>   Of course, that far too imaganable picture, just like my previous
>massage has, just like several years ago cygwin itself was only
>imaganable. I don't believe that things enpictured by me will be, or
>even should be, done to cygwin. I just wanted to hyperbolize it,
>showing that changing itself is not an edge alternative, all
>determained by ammount of changes, and there might be the golden mean,
>exactly what you'll do. (That's just because I have a ho that Cygnus
>guys quite conservative - I remember Christopher Faylor's hesitating
>in cygwin-developer whether correcting bug won't break user (or
>customer) code. Maybe you, Corinna, as leading contributor, and DJ, as
>author of alternative approach, and working for Cygnus, have other
>opinions).

I have no idea what, specifically, you are referring to but it is
interesting that you find it "quite conservative" to consider caring
about breaking somebody's code.  You are probably referring to my
soliciting of opinions on the subject of breaking API compatibility
with a new cygwin DLL.  This was obviously a subject which deserved
careful consideration and it was something that I was willing to do.
In fact, it is something that *will* occur in a future release.

Regardless, if you look at the ChangeLog in the last year, you'll find
that I'm the author of a lot of radical changes in Cygwin.

I am not at all opposed to the idea of somebody fixing ftell/fseek
to work as Microsoft has documented them or as DJGPP has currently
implemented things.  I've written a stdio layer myself and I know
that this is not a trivial undertaking, though.  Certainly no
one at Cygnus has the time right now to undertake this.

Currently, Corinna, Mumit, and a couple of other people are the only
outside contributers to the project.  Everyone else seems to be in
"Cygwin doesn't work the way I think it should when I run program X.
Here's the error message." mode.

I'm collecting the error messages and hope to investigate problems but
the reality is that this is a volunteer effort for DJ and me.  Our
real jobs don't offer much time for tracking down net problems.

-chris

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

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

[Corinna Vinschen]

Paul Sokolovsky wrote:
>     So, for more than twenty years MS maintains myth about "special
> format" of text files of their systems. It's hardly believable. Since
> my old XT I quite nicely handled any text files - be they Unix \xa,
> Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
> "special" format of text files. Most tools available handled any type,
> and conversion between formats was quite feasible. With win32, such
> problems are ceased at all - I don't have no line endings problems, no
> encoding problems, even that unicode seams to be here.

As a matter of fact: Peter's c example, which opens this thread, does
not work with VC++, if the newline is not \r\n. Look into the source
of M$-ftell(), it can't work.

The best way would be to throw away and ignore any newline with
more than one single character.

But let's get serious.

IMHO, above all text file processing should be done according to the
underlying OS and it's vendor, also if this is wretched.

The second choice has the advantage, to be easy to implement.

The third choice should be implemented, if s.o. has nothing important
to do.

Regards,
Corinna


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

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

[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.

> >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

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

[Christopher Faylor]

On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
>
>Ok I appoligize.
>
>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
>on input.  In files opened for reading/writing, fopen and all related
>routines check for a CTRL+Z at the end of the file and remove it if
>possible.  This is done because using fseek and ftell to move within
>an file that ends in CTRL+Z may cause fseek to behave improperly near
>the end of the file.
>
>---
>
>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?
>
>Sorry for speaking out of line,

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.

-chris

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

[Earnie Boyd]

Ok I appoligize.

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
on input.  In files opened for reading/writing, fopen and all related
routines check for a CTRL+Z at the end of the file and remove it if
possible.  This is done because using fseek and ftell to move within
an file that ends in CTRL+Z may cause fseek to behave improperly near
the end of the file.

---

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?

Sorry for speaking out of line,
Earnie.

---Peter Kabal <kabal@ece.mcgill.ca> wrote:
>
> I did.  I quote from Harbison and Steele, Fourth edition, p 353.
> 
> "The following, more limited set of calls is permitted on text streams
> by ISO C:
> 
> fseek (stream, 0L, SEEK_SET)
> fseek (stream, 0L, SEEK_CUR)
> fseek (stream, 0L, SEEK_END)
> fseek (stream, 0L, ftell_pos, SEEK_SET)  at a position returned by a
>     previous call to ftell for stream.
> "
> 
> I <did> read the docs about "text mode processing"!  Your comment was
> unwarranted and warrants an apology.
> 
> > -----Original Message-----
> > From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> > Sent: February 16, 1999 8:28 AM
> > To: kabal@ece.mcgill.ca
> > Cc: cygwin users
> > Subject: Re: Cygwin B20 - fseek under gcc fails to reposition on
text
> > files
> > 
> > 
> > 
> > You need to read the docs about "text mode processing".  This is
> > exactly the expected behavior.  If you're going to use these
functions
> > then you must process in binary mode.
> > 
> > Regards,
> > Earnie.
> > 
> > ---Peter Kabal <kabal@ECE.McGill.CA> wrote:
> > >
> > > Consider a text file (CR/LF line endings).  Read a line, save the
> > > current position, seek to end-of-file, seek to the saved position,
> > > read a line.  The second read does not return the second line of
> > > the file.
> > > 
> > > A shell script which tests the problem is included below:
> > >
---------------------------------------------------------------------
> > > #!/bin/sh
> > > #
> > > # Test fseek bug
> > > # On Cygwin 20.1, a file is not correctly repositioned after
seeking
> > to the
> > > # end-of-file on a text file (CR/LF line endings).
> > > 
> > > cat > tfrepos.c << EoF
> > > #include <stdio.h>
> > > int main (int argc, char *argv[])
> > > {
> > >   FILE *fp;
> > >   long int pos, size;
> > >   char line[200];
> > >   char *p;
> > > 
> > >   fp = fopen (argv[1], "r");
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   pos = ftell (fp);
> > >   fseek (fp, 0L, SEEK_END);
> > >   fseek (fp, pos, SEEK_SET);
> > > 
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   return 0;
> > > }
> > > EoF
> > > 
> > > # Run the test program with the c-program as input
> > > gcc tfrepos.c -o tfrepos
> > > ./tfrepos tfrepos.c
> > > 
> > > # Clean up
> > > rm -f tfrepos tfrepos.c
> > >
---------------------------------------------------------------------
> > > 
> > > Peter Kabal  kabal@ECE.McGill.CA
> > > Dept. Electrical & Computer Eng.
> > > McGill University 
> > > 
> > 
> > _________________________________________________________
> > DO YOU YAHOO!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> > 
> > 
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

[Peter Kabal]

Consider a text file (CR/LF line endings).  Read a line, save the
current position, seek to end-of-file, seek to the saved position,
read a line.  The second read does not return the second line of
the file.

A shell script which tests the problem is included below:
---------------------------------------------------------------------
#!/bin/sh
#
# Test fseek bug
# On Cygwin 20.1, a file is not correctly repositioned after seeking to the
# end-of-file on a text file (CR/LF line endings).

cat > tfrepos.c << EoF
#include <stdio.h>
int main (int argc, char *argv[])
{
  FILE *fp;
  long int pos, size;
  char line[200];
  char *p;

  fp = fopen (argv[1], "r");
  p = fgets (line, 200, fp);
  printf (" Line: %s", p);

  pos = ftell (fp);
  fseek (fp, 0L, SEEK_END);
  fseek (fp, pos, SEEK_SET);

  p = fgets (line, 200, fp);
  printf (" Line: %s", p);

  return 0;
}
EoF

# Run the test program with the c-program as input
gcc tfrepos.c -o tfrepos
./tfrepos tfrepos.c

# Clean up
rm -f tfrepos tfrepos.c
---------------------------------------------------------------------

Peter Kabal  kabal@ECE.McGill.CA
Dept. Electrical & Computer Eng.
McGill University 

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

[Peter Kabal]

Consider a text file (CR/LF line endings).  Read a line, save the
current position, seek to end-of-file, seek to the saved position,
read a line.  The second read does not return the second line of
the file.

A shell script which tests the problem is included below:
---------------------------------------------------------------------
#!/bin/sh
#
# Test fseek bug
# On Cygwin 20.1, a file is not correctly repositioned after seeking to the
# end-of-file on a text file (CR/LF line endings).

cat > tfrepos.c << EoF
#include <stdio.h>
int main (int argc, char *argv[])
{
  FILE *fp;
  long int pos, size;
  char line[200];
  char *p;

  fp = fopen (argv[1], "r");
  p = fgets (line, 200, fp);
  printf (" Line: %s", p);

  pos = ftell (fp);
  fseek (fp, 0L, SEEK_END);
  fseek (fp, pos, SEEK_SET);

  p = fgets (line, 200, fp);
  printf (" Line: %s", p);

  return 0;
}
EoF

# Run the test program with the c-program as input
gcc tfrepos.c -o tfrepos
./tfrepos tfrepos.c

# Clean up
rm -f tfrepos tfrepos.c
---------------------------------------------------------------------

Peter Kabal  kabal@ECE.McGill.CA
Dept. Electrical & Computer Eng.
McGill University