RE: setmode (long)

RE: setmode (long)

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3063 bytes --]

> -----Original Message-----
> From: E. Robert Tisdale [ mailto:edwin@netwood.net ]
> Sent: Friday, February 26, 1999 7:27 AM
> To: cygwin@sourceware.cygnus.com
> Subject: Re: setmode (long)
> 
> 
> Mumit Khan wrote:
> 
> > I believe Pierre has something here.
> > I took another look at your code,
> > and you're changing the mode of a buffered stream!
> > Could you flush the stream (stream << flush)
> > before changing the mode and see what happens?
> 
> No, I can't just now.
> I sent the computer with Windows 98
> and the DJPP and Cygnus compilers to my brother-in-law.
> You'll have to wait until I can fire up my old Windows 95.
> 
> > I don't believe that your code is well-defined,
> > since changing anything for an underlying descriptor
> > of a buffered stream without flushing
> > is not guaranteed to produce the desired effect.
> 
> Can you tell me where I can get documentation
> for this behavior in setmode?
> I got the file descriptors for standard I/O from
> 
> 0 == (cin.rdbuf())->_fileno
> 1 == (cout.rdbuf())->_fileno
> 2 == (cerr.rdbuf())->_fileno
> 
> because a
> ostdiostream has a
> stdiobuf which is a
> filebuf which is a
> streambuf which is a
> _IO_FILE which has an
> int _fileno.
> 
> Is there a portable way to get file descriptors
> for cin, cout, cerr and clog?
> 
> I suspect that Pierre may indeed have part of the answer
> for his Windows 95 OS and his Emacs shell
> but it doesn't explain why my `test.out' files
> appear to be written in binary mode
> even when the last mode set is text mode.
> 

This has in fact nothing to do with win95/98/...; it's a conceptual
problem. You should *never* twiddle the underlying file descriptor when
using *any* kind of buffered stream! The problem is that the buffered
stream is optimizing out a lot of the calls to the underlying file
descriptor. It may even happen that the buffered stream cache some of
the characteristics of the underlying file descriptor to optimize
performance in its own handling of data :-)

You *may* try to use fflush() before, but you have the same problem with
the iostream, so you may have to flush them. But note that flush only
guarantee that you flush the output buffer of the stream, not that you
flush any internal cache.

Well behaved buffered streams (I don't know for those you use) should
have an fsetmode() (for stdio) or stream::setmode() (for iosteams) call
that do the setmode in the proper way so that you get the expected
result. *Any* other attempt to hack on th efile descriptor of an opened
buffered stream is *guaranteed* to be opened to subtle misbehaviours,
and (for once :-) Micro$oft is not responsible here...

HTH

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

RE: setmode (long)

[Bernard Dautrevaux]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3064 bytes --]

> -----Original Message-----
> From: E. Robert Tisdale [ mailto:edwin@netwood.net ]
> Sent: Friday, February 26, 1999 7:27 AM
> To: cygwin@sourceware.cygnus.com
> Subject: Re: setmode (long)
> 
> 
> Mumit Khan wrote:
> 
> > I believe Pierre has something here.
> > I took another look at your code,
> > and you're changing the mode of a buffered stream!
> > Could you flush the stream (stream << flush)
> > before changing the mode and see what happens?
> 
> No, I can't just now.
> I sent the computer with Windows 98
> and the DJPP and Cygnus compilers to my brother-in-law.
> You'll have to wait until I can fire up my old Windows 95.
> 
> > I don't believe that your code is well-defined,
> > since changing anything for an underlying descriptor
> > of a buffered stream without flushing
> > is not guaranteed to produce the desired effect.
> 
> Can you tell me where I can get documentation
> for this behavior in setmode?
> I got the file descriptors for standard I/O from
> 
> 0 == (cin.rdbuf())->_fileno
> 1 == (cout.rdbuf())->_fileno
> 2 == (cerr.rdbuf())->_fileno
> 
> because a
> ostdiostream has a
> stdiobuf which is a
> filebuf which is a
> streambuf which is a
> _IO_FILE which has an
> int _fileno.
> 
> Is there a portable way to get file descriptors
> for cin, cout, cerr and clog?
> 
> I suspect that Pierre may indeed have part of the answer
> for his Windows 95 OS and his Emacs shell
> but it doesn't explain why my `test.out' files
> appear to be written in binary mode
> even when the last mode set is text mode.
> 

This has in fact nothing to do with win95/98/...; it's a conceptual
problem. You should *never* twiddle the underlying file descriptor when
using *any* kind of buffered stream! The problem is that the buffered
stream is optimizing out a lot of the calls to the underlying file
descriptor. It may even happen that the buffered stream cache some of
the characteristics of the underlying file descriptor to optimize
performance in its own handling of data :-)

You *may* try to use fflush() before, but you have the same problem with
the iostream, so you may have to flush them. But note that flush only
guarantee that you flush the output buffer of the stream, not that you
flush any internal cache.

Well behaved buffered streams (I don't know for those you use) should
have an fsetmode() (for stdio) or stream::setmode() (for iosteams) call
that do the setmode in the proper way so that you get the expected
result. *Any* other attempt to hack on th efile descriptor of an opened
buffered stream is *guaranteed* to be opened to subtle misbehaviours,
and (for once :-) Micro$oft is not responsible here...

HTH

		Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

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

Re: setmode (long)

[E. Robert Tisdale]

Bernard Dautrevaux wrote:

> Well behaved buffered streams (I don't know for those you use)
> should have an fsetmode() (for stdio)
> or stream::setmode() (for iosteams) call
> that do the setmode in the proper way
> so that you get the expected result.
> *Any* other attempt to hack on the file descriptor
> of an opened buffered stream
> is *guaranteed* to be opened to subtle misbehaviors,
> and (for once :-) Micro$oft is not responsible here...

I'm not sure what you are talking about
or who you are talking to here.
I couldn't find fsetmode() or stream::setmode()
in any of my Cygwin-b20 header files.

E. Robert Tisdale <edwin@netwood.net>


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

Re: setmode (long)

[E. Robert Tisdale]

Bernard Dautrevaux wrote:

> Well behaved buffered streams (I don't know for those you use)
> should have an fsetmode() (for stdio)
> or stream::setmode() (for iosteams) call
> that do the setmode in the proper way
> so that you get the expected result.
> *Any* other attempt to hack on the file descriptor
> of an opened buffered stream
> is *guaranteed* to be opened to subtle misbehaviors,
> and (for once :-) Micro$oft is not responsible here...

I'm not sure what you are talking about
or who you are talking to here.
I couldn't find fsetmode() or stream::setmode()
in any of my Cygwin-b20 header files.

E. Robert Tisdale <edwin@netwood.net>


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

Re: setmode (long)

[E. Robert Tisdale]

Christopher Faylor wrote:

> On Thu, Feb 25, 1999 at 01:23:29AM -0800,
> E. Robert Tisdale wrote:
> >Should I download the latest snapshot
> >and use it to compile my application programs?
> >Or should I wait until the next release
> >before upgrading my compiler?
>
> That's not a decision I can make.  You're welcome to try a snapshot
> but snapshots carry no guarantees as far as stability is concerned.
> However, this is a DLL problem
> so you should not have to recompile your program to see a benefit.

Duh... Which DLL?

Thanks in advance, E. Robert Tisdale <edwin@netwood.net>



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

Re: setmode (long)

[Christopher Faylor]

On Thu, Feb 25, 1999 at 01:23:29AM -0800, E. Robert Tisdale wrote:
>Christopher Faylor wrote:
>> That's right in older Cygwin's
>> setting the mode to TEXT didn't necessarily change the mode.
>> This should be fixed in the snapshots.
>>
>> We have gone around and around on this behavior in the developers list
>> but I think that the current implementation is correct.
>
>What do you mean by "older Cygwin's"?
>I downloaded Beta 20.1 and installed it.
>
>Do you mean that the problem has already been fixed in the snapshots?
>Has anyone actually tested (test'd) the snapshots
>to determine whether this behavior still persists or not?

Yes.  I meant that this has been fixed in the latest snapshots.

>Should I download the latest snapshot
>and use it to compile my application programs?
>Or should I wait until the next release
>before upgrading my compiler?

That's not a decision I can make.  You're welcome to try a snapshot
but snapshots carry no guarantees as far as stability is concerned.
However, this is a DLL problem so you should not have to recompile
your program to see a benefit.

cgf

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

Re: setmode (long)

[Chris Faylor]

On Wed, Mar 03, 1999 at 07:26:05PM -0800, E. Robert Tisdale wrote:
>Christopher Faylor wrote:
>> On Thu, Feb 25, 1999 at 01:23:29AM -0800,
>> E. Robert Tisdale wrote:
>> >Should I download the latest snapshot
>> >and use it to compile my application programs?
>> >Or should I wait until the next release
>> >before upgrading my compiler?
>>
>> That's not a decision I can make.  You're welcome to try a snapshot
>> but snapshots carry no guarantees as far as stability is concerned.
>> However, this is a DLL problem
>> so you should not have to recompile your program to see a benefit.
>
>Duh... Which DLL?
>
>Thanks in advance, E. Robert Tisdale <edwin@netwood.net>

Huh?  The *cygwin* DLL.  What other DLL would I possibly be talking about?

Possibly you are asking exactly which snapshot to download.  I have no
idea when this was changed but you can check the ChangeLogs.

cgf

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

Re: setmode (long)

[Chris Faylor]

On Wed, Mar 03, 1999 at 07:26:05PM -0800, E. Robert Tisdale wrote:
>Christopher Faylor wrote:
>> On Thu, Feb 25, 1999 at 01:23:29AM -0800,
>> E. Robert Tisdale wrote:
>> >Should I download the latest snapshot
>> >and use it to compile my application programs?
>> >Or should I wait until the next release
>> >before upgrading my compiler?
>>
>> That's not a decision I can make.  You're welcome to try a snapshot
>> but snapshots carry no guarantees as far as stability is concerned.
>> However, this is a DLL problem
>> so you should not have to recompile your program to see a benefit.
>
>Duh... Which DLL?
>
>Thanks in advance, E. Robert Tisdale <edwin@netwood.net>

Huh?  The *cygwin* DLL.  What other DLL would I possibly be talking about?

Possibly you are asking exactly which snapshot to download.  I have no
idea when this was changed but you can check the ChangeLogs.

cgf

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

Re: setmode (long)

[E. Robert Tisdale]

Christopher Faylor wrote:

> On Thu, Feb 25, 1999 at 01:23:29AM -0800,
> E. Robert Tisdale wrote:
> >Should I download the latest snapshot
> >and use it to compile my application programs?
> >Or should I wait until the next release
> >before upgrading my compiler?
>
> That's not a decision I can make.  You're welcome to try a snapshot
> but snapshots carry no guarantees as far as stability is concerned.
> However, this is a DLL problem
> so you should not have to recompile your program to see a benefit.

Duh... Which DLL?

Thanks in advance, E. Robert Tisdale <edwin@netwood.net>



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

Re: setmode (long)

[Christopher Faylor]

On Thu, Feb 25, 1999 at 01:23:29AM -0800, E. Robert Tisdale wrote:
>Christopher Faylor wrote:
>> That's right in older Cygwin's
>> setting the mode to TEXT didn't necessarily change the mode.
>> This should be fixed in the snapshots.
>>
>> We have gone around and around on this behavior in the developers list
>> but I think that the current implementation is correct.
>
>What do you mean by "older Cygwin's"?
>I downloaded Beta 20.1 and installed it.
>
>Do you mean that the problem has already been fixed in the snapshots?
>Has anyone actually tested (test'd) the snapshots
>to determine whether this behavior still persists or not?

Yes.  I meant that this has been fixed in the latest snapshots.

>Should I download the latest snapshot
>and use it to compile my application programs?
>Or should I wait until the next release
>before upgrading my compiler?

That's not a decision I can make.  You're welcome to try a snapshot
but snapshots carry no guarantees as far as stability is concerned.
However, this is a DLL problem so you should not have to recompile
your program to see a benefit.

cgf

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

Re: setmode (long)

[Christopher Faylor]

On Tue, Feb 23, 1999 at 10:19:47PM -0800, E. Robert Tisdale wrote:
>...shows that test.out was opened in binary mode
>and setmode didn't switch to text mode.

That's right in older Cygwin's setting the mode to TEXT didn't
necessarily change the mode.  This should be fixed in the
snapshots.

We have gone around and around on this behavior in the developers
list but I think that the current implementation is correct.

cgf

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

Re: setmode (long)

[Mumit Khan]

On Thu, 25 Feb 1999, E. Robert Tisdale wrote:

> 
> Does anyone know whether the DJGPP compiler
> has been fixed and tested yet?
> 

You can always try it.

I did run your code using mingw32 and MSVC and it gives the same output.

Mumit


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

Re: setmode (long)

[E. Robert Tisdale]

Pierre A. Humblet wrote:

> I had a second look (b20.1 on win95) at your problem
> and it's not what I thought initially,
> i.e. a basic problem with the cygwin layer in b20.1,
> which tends to open too many files as binary.
>
> In your output, each time you look at test.out
> the FIRST return of setmode is the same as the argument of setmode,
> i.e. O_TEXT. Thus in all your runs the file was initially TEXT,
> although the output appears to be binary.
> At any rate setmode had no effect.
>
> Next I duplicated your experiments (standard g++ in b20.1 only).
> I don't trust editors to look at CR in files and used "od -c test.out".
> That shows an extra  ^M on all lines compared to your output.
> On a binary mounted system test.out is initially binary (as it should),
> but the output is the same.  Also setmode works for stdout.
>
> Next I wrote a similar test in C. There setmode works as expected.
>
> I am wondering what you see if you look at your files with od -c,
> and if you agree that setmode works in a C program
> (that would point to a C++ error (?))

I verified the results of `vi' (`vim' not `elvis')
with the results of `od' before I sent the original message.
I included the results from `vi' in my original message
because they are easier to read.
I thought it would be obvious from the `test.dos' and `test.cyg' output
that `vi' accurately represented the actual contents of the file.

Do `vi' and `od' give you different results on your system?

E. Robert Tisdale <edwin@netwood.net>


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

Re: setmode (long)

[Pierre A. Humblet]

At 12:09 PM 2/25/99 -0800, E. Robert Tisdale wrote:
Robert,

As I said, at least on my machine, od -c shows all lines of test.out ending with \r \n. Now when I modify your program end remove the third setmode, which switches back to TEXT, then all lines appear in binary mode!
Here is a possible explanation: your program is not flushing the buffer and the "effective" mode is the last one, at the time data is moved to disk.
stdout is flushed more often, that's why it works.

Pierre

>Pierre A. Humblet wrote:
>
>> I had a second look (b20.1 on win95) at your problem
>> and it's not what I thought initially,
>> i.e. a basic problem with the cygwin layer in b20.1,
>> which tends to open too many files as binary.
>>
>> In your output, each time you look at test.out
>> the FIRST return of setmode is the same as the argument of setmode,
>> i.e. O_TEXT. Thus in all your runs the file was initially TEXT,
>> although the output appears to be binary.
>> At any rate setmode had no effect.
>>
>> Next I duplicated your experiments (standard g++ in b20.1 only).
>> I don't trust editors to look at CR in files and used "od -c test.out".
>> That shows an extra  ^M on all lines compared to your output.
>> On a binary mounted system test.out is initially binary (as it should),
>> but the output is the same.  Also setmode works for stdout.
>>
>> Next I wrote a similar test in C. There setmode works as expected.
>>
>> I am wondering what you see if you look at your files with od -c,
>> and if you agree that setmode works in a C program
>> (that would point to a C++ error (?))
>
>I verified the results of `vi' (`vim' not `elvis')
>with the results of `od' before I sent the original message.
>I included the results from `vi' in my original message
>because they are easier to read.
>I thought it would be obvious from the `test.dos' and `test.cyg' output
>that `vi' accurately represented the actual contents of the file.
>
>Do `vi' and `od' give you different results on your system?
>
>E. Robert Tisdale <edwin@netwood.net>
>


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

Re: setmode (long)

[Mumit Khan]

"Pierre A. Humblet" <Pierre.Humblet@eurecom.fr> writes:
> At 12:09 PM 2/25/99 -0800, E. Robert Tisdale wrote:
> Robert,
> 
> As I said, at least on my machine, od -c shows all lines of test.out ending w
> ith \r \n. Now when I modify your program end remove the third setmode, which
>  switches back to TEXT, then all lines appear in binary mode!
> Here is a possible explanation: your program is not flushing the buffer and t
> he "effective" mode is the last one, at the time data is moved to disk.
> stdout is flushed more often, that's why it works.
> 

I believe Pierre has something here. I took another look at your code, and
you're changing the mode of a buffered stream! Could you flush the
stream (stream << flush) before changing the mode and see what happens?

I don't believe that your code is well-defined, since changing anything
for an underlying descriptor of a buffered stream without flushing is
not guaranteed to produce the desired effect.

Regards,
Mumit


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

Re: setmode (long)

[DJ Delorie]

> Does anyone know whether the DJGPP compiler has been fixed and
> tested yet?

I don't know of any fixes relevent to this, but you might try using
egcs for djgpp instead of gcc - it has a different C++ library.

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

Re: setmode (long)

[E. Robert Tisdale]

Mumit Khan wrote:

> I believe Pierre has something here.
> I took another look at your code,
> and you're changing the mode of a buffered stream!
> Could you flush the stream (stream << flush)
> before changing the mode and see what happens?

No, I can't just now.
I sent the computer with Windows 98
and the DJPP and Cygnus compilers to my brother-in-law.
You'll have to wait until I can fire up my old Windows 95.

> I don't believe that your code is well-defined,
> since changing anything for an underlying descriptor
> of a buffered stream without flushing
> is not guaranteed to produce the desired effect.

Can you tell me where I can get documentation
for this behavior in setmode?
I got the file descriptors for standard I/O from

0 == (cin.rdbuf())->_fileno
1 == (cout.rdbuf())->_fileno
2 == (cerr.rdbuf())->_fileno

because a
ostdiostream has a
stdiobuf which is a
filebuf which is a
streambuf which is a
_IO_FILE which has an
int _fileno.

Is there a portable way to get file descriptors
for cin, cout, cerr and clog?

I suspect that Pierre may indeed have part of the answer
for his Windows 95 OS and his Emacs shell
but it doesn't explain why my `test.out' files
appear to be written in binary mode
even when the last mode set is text mode.

E. Robert Tisdale <edwin@netwood.net>




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

Re: setmode (long)

[E. Robert Tisdale]

DJ Delorie wrote:

> > Does anyone know whether the DJGPP compiler has been fixed and
> > tested yet?
>
> I don't know of any fixes relevent to this, but you might try using
> egcs for djgpp instead of gcc - it has a different C++ library.

How many compilers are there?
I got my DJGPP compiler by following the links

    CYGWIN-->Related Sites-->DJGPP Home Page-->Zip Picker

from

    http://www.cygnus.com/

and I think I ended up getting the files from

    ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/

Do I need to go somewhere else to get the egcs compiler?

Thanks in advance, E. Robert Tisdale <edwin@netwood.net>


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

Re: setmode (long)

[E. Robert Tisdale]

Christopher Faylor wrote:

> That's right in older Cygwin's
> setting the mode to TEXT didn't necessarily change the mode.
> This should be fixed in the snapshots.
>
> We have gone around and around on this behavior in the developers list
> but I think that the current implementation is correct.

What do you mean by "older Cygwin's"?
I downloaded Beta 20.1 and installed it.

Do you mean that the problem has already been fixed in the snapshots?
Has anyone actually tested (test'd) the snapshots
to determine whether this behavior still persists or not?

Should I download the latest snapshot
and use it to compile my application programs?
Or should I wait until the next release
before upgrading my compiler?

Does anyone know whether the DJGPP compiler
has been fixed and tested yet?

Thanks in advance, E. Robert Tisdale <edwin@netwood.net>



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

Re: setmode (long)

[E. Robert Tisdale]

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

setmode (long)

[E. Robert Tisdale]

I have written an application in C++ which is supposed to compile
and run on any platform including UNIX, DOS and Windows 95/98/NT.
It reads and writes text as well as binary data from files and
standard input and output.  It uses the line feed (newline) character
to mark the end of a line and the carriage return line feed sequence
to mark the end of a paragraph.  It reads and writes text files
in binary mode and converts \r\n to \n on input and \n to \r\n
on output for DOS (and Windows 95/98/NT) systems so that the user
can read, edit and print them using native tools.

On DOS and Windows 95/98/NT systems, the C preprocessor includes code
which uses setmode to change the default I/O mode from text to binary.
This worked just fine with older versions of DJGPP on DOS
but I have just downloaded and installed the most recent versions
of DJGPP, Cygwin and mingw32 and I am experiencing some problems.
I wrote a short program, `test.cc', to help illustrate them.
----------------------------------------------------------------------

// test.cc

#include<fstream.h>
#include<io.h>
#include<fcntl.h>

int
main() {
  int   oldmode = 0;
  cout << "default mode:\n";
  cout << "  0 carriage returns\n";
  cout << "  1 carriage returns\r\n";
  cout << "  2 carriage returns\r\r\n";
  cout << "  3 carriage returns\r\r\r\n";
  oldmode = setmode(1, O_TEXT);
  cout << hex << oldmode <<
    " = setmode(1, " << hex << O_TEXT   << "):\n";
  cout << "  0 carriage returns\n";
  cout << "  1 carriage returns\r\n";
  cout << "  2 carriage returns\r\r\n";
  cout << "  3 carriage returns\r\r\r\n";
  oldmode = setmode(1, O_BINARY);
  cout << hex << oldmode <<
    " = setmode(1, " << hex << O_BINARY << "):\n";
  cout << "  0 carriage returns\n";
  cout << "  1 carriage returns\r\n";
  cout << "  2 carriage returns\r\r\n";
  cout << "  3 carriage returns\r\r\r\n";
  oldmode = setmode(1, O_TEXT);
  cout << hex << oldmode <<
    " = setmode(1, " << hex << O_TEXT   << "):\n";
  cout << "  0 carriage returns\n";
  cout << "  1 carriage returns\r\n";
  cout << "  2 carriage returns\r\r\n";
  cout << "  3 carriage returns\r\r\r\n";

  ofstream      test_out("test.out", ios::out);
  test_out << "default mode:\n";
  test_out << "  0 carriage returns\n";
  test_out << "  1 carriage returns\r\n";
  test_out << "  2 carriage returns\r\r\n";
  test_out << "  3 carriage returns\r\r\r\n";
  oldmode = setmode((test_out.rdbuf())->fd(), O_TEXT);
  test_out << hex << oldmode <<
    " = setmode((test_out.rdbuf())->fd(), " << hex << O_TEXT   << "):\n";
  test_out << "  0 carriage returns\n";
  test_out << "  1 carriage returns\r\n";
  test_out << "  2 carriage returns\r\r\n";
  test_out << "  3 carriage returns\r\r\r\n";
  oldmode = setmode((test_out.rdbuf())->fd(), O_BINARY);
  test_out << hex << oldmode <<
    " = setmode((test_out.rdbuf())->fd(), " << hex << O_BINARY << "):\n";
  test_out << "  0 carriage returns\n";
  test_out << "  1 carriage returns\r\n";
  test_out << "  2 carriage returns\r\r\n";
  test_out << "  3 carriage returns\r\r\r\n";
  oldmode = setmode((test_out.rdbuf())->fd(), O_TEXT);
  test_out << hex << oldmode <<
    " = setmode((test_out.rdbuf())->fd(), " << hex << O_TEXT   << "):\n";
  test_out << "  0 carriage returns\n";
  test_out << "  1 carriage returns\r\n";
  test_out << "  2 carriage returns\r\r\n";
  test_out << "  3 carriage returns\r\r\r\n";
  return 0;
  }
----------------------------------------------------------------------

I compiled under Windows 98 using DJGPP and a DOS shell (MS-DOS Prompt)

        >gxx -v -w -O2 -o test test.cc -lgpp

and I ran the test program

        >.\test > test.dos

I started a Cygwin-b20 bash shell and examined the results:

        $ vi test.dos
        default mode:^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M
        8 = setmode(1, 8):^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M
        8 = setmode(1, 4):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        4 = setmode(1, 8):^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M

appears to be correct but

        $ vi test.out
        default mode:
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        8 = setmode((test_out.rdbuf())->fd(), 8):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        8 = setmode((test_out.rdbuf())->fd(), 4):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        4 = setmode((test_out.rdbuf())->fd(), 8):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M

shows that test.out was opened in binary mode
and setmode didn't switch to text mode.

----------------------------------------------------------------------

I compiled under Windows 98 using EGCS Cygwin-b20 and a bash shell

        $ g++ -v -Wall -O2 -o test test.cc

ran the test program

        $ ./test > test.cyg

and examined the results:

        $ vi test.cyg
        default mode:^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M
        20000 = setmode(1, 20000):^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M
        20000 = setmode(1, 10000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        10000 = setmode(1, 20000):^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M

appears to be correct but

        $ vi test.out
        default mode:
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        20000 = setmode((test_out.rdbuf())->fd(), 20000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        20000 = setmode((test_out.rdbuf())->fd(), 10000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        10000 = setmode((test_out.rdbuf())->fd(), 20000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M

shows that test.out was opened in binary mode
and setmode didn't switch to text mode.

----------------------------------------------------------------------

I re-compiled under Windows 98 using EGCS Cygwin-b20 with mingw32

        $ g++ -L/mingw32/lib -L/mingw32/i386-mingw32/lib \
        -L/mingw32/lib/gcc-lib/i386-mingw32/egcs-2.91.60 \
        -v -Wall -O2 -mno-cygwin -o test test.cc -lstdc++ -liberty

and ran the test program using and a DOS shell (MS-DOS Prompt)

        >.\test > test.win

I used the Cygwin-b20 bash shell to examine the results:

        $ vi test.win
        default mode:
          0 carriage returns
          1 carriage returns
          2 carriage returns
          3 carriage returns
        4000 = setmode(1, 4000):
          0 carriage returns
          1 carriage returns
          2 carriage returns
          3 carriage returns
        4000 = setmode(1, 8000):
          0 carriage returns
          1 carriage returns
          2 carriage returns
          3 carriage returns
        8000 = setmode(1, 4000):
          0 carriage returns
          1 carriage returns
          2 carriage returns
          3 carriage returns

contains no carriage returns and

       $ vi test.out
        default mode:
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        4000 = setmode((test_out.rdbuf())->fd(), 4000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        4000 = setmode((test_out.rdbuf())->fd(), 8000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        8000 = setmode((test_out.rdbuf())->fd(), 4000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M

shows that test.out was opened in binary mode
and setmode didn't switch to text mode.

----------------------------------------------------------------------

I didn't change any of the default settings when I installed Cygwin.
I didn't mount any file systems as binary only or define binmode.
I've read the FAQs and searched the mailing list archives.

It appears to me that there are still very serious problems
with text and binary I/O in DJGPP, Cygwin-b20 and mingw32
using Cygwin-b20 bash and MS-DOS Prompt under Windows 98.

Also, all the information regarding text and binary I/O
seems to be scattered across many different documents.
I think it would help me and other portable application
programmers if someone could put it all together
in one place with expicit references to the specific
operating system, compiler and shell to which it applies.

Thanks in advance, E. Robert Tisdale <edwin@netwood.net>

NOTE:   My editor, `vi', displays a carriage return as ^M
        but the line feed at the end of the line is invisible.
        My DOS shell is C:\WINDOWS\COMMAND.COM



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

Re: setmode (long)

[E. Robert Tisdale]

DJ Delorie wrote:

> > Does anyone know whether the DJGPP compiler has been fixed and
> > tested yet?
>
> I don't know of any fixes relevent to this, but you might try using
> egcs for djgpp instead of gcc - it has a different C++ library.

How many compilers are there?
I got my DJGPP compiler by following the links

    CYGWIN-->Related Sites-->DJGPP Home Page-->Zip Picker

from

    http://www.cygnus.com/

and I think I ended up getting the files from

    ftp://ftp.simtel.net/pub/simtelnet/gnu/djgpp/

Do I need to go somewhere else to get the egcs compiler?

Thanks in advance, E. Robert Tisdale <edwin@netwood.net>


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

Re: setmode (long)

[E. Robert Tisdale]

Mumit Khan wrote:

> I believe Pierre has something here.
> I took another look at your code,
> and you're changing the mode of a buffered stream!
> Could you flush the stream (stream << flush)
> before changing the mode and see what happens?

No, I can't just now.
I sent the computer with Windows 98
and the DJPP and Cygnus compilers to my brother-in-law.
You'll have to wait until I can fire up my old Windows 95.

> I don't believe that your code is well-defined,
> since changing anything for an underlying descriptor
> of a buffered stream without flushing
> is not guaranteed to produce the desired effect.

Can you tell me where I can get documentation
for this behavior in setmode?
I got the file descriptors for standard I/O from

0 == (cin.rdbuf())->_fileno
1 == (cout.rdbuf())->_fileno
2 == (cerr.rdbuf())->_fileno

because a
ostdiostream has a
stdiobuf which is a
filebuf which is a
streambuf which is a
_IO_FILE which has an
int _fileno.

Is there a portable way to get file descriptors
for cin, cout, cerr and clog?

I suspect that Pierre may indeed have part of the answer
for his Windows 95 OS and his Emacs shell
but it doesn't explain why my `test.out' files
appear to be written in binary mode
even when the last mode set is text mode.

E. Robert Tisdale <edwin@netwood.net>




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

Re: setmode (long)

[E. Robert Tisdale]

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

Re: setmode (long)

[Mumit Khan]

"Pierre A. Humblet" <Pierre.Humblet@eurecom.fr> writes:
> At 12:09 PM 2/25/99 -0800, E. Robert Tisdale wrote:
> Robert,
> 
> As I said, at least on my machine, od -c shows all lines of test.out ending w
> ith \r \n. Now when I modify your program end remove the third setmode, which
>  switches back to TEXT, then all lines appear in binary mode!
> Here is a possible explanation: your program is not flushing the buffer and t
> he "effective" mode is the last one, at the time data is moved to disk.
> stdout is flushed more often, that's why it works.
> 

I believe Pierre has something here. I took another look at your code, and
you're changing the mode of a buffered stream! Could you flush the
stream (stream << flush) before changing the mode and see what happens?

I don't believe that your code is well-defined, since changing anything
for an underlying descriptor of a buffered stream without flushing is
not guaranteed to produce the desired effect.

Regards,
Mumit


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

Re: setmode (long)

[Pierre A. Humblet]

At 12:09 PM 2/25/99 -0800, E. Robert Tisdale wrote:
Robert,

As I said, at least on my machine, od -c shows all lines of test.out ending with \r \n. Now when I modify your program end remove the third setmode, which switches back to TEXT, then all lines appear in binary mode!
Here is a possible explanation: your program is not flushing the buffer and the "effective" mode is the last one, at the time data is moved to disk.
stdout is flushed more often, that's why it works.

Pierre

>Pierre A. Humblet wrote:
>
>> I had a second look (b20.1 on win95) at your problem
>> and it's not what I thought initially,
>> i.e. a basic problem with the cygwin layer in b20.1,
>> which tends to open too many files as binary.
>>
>> In your output, each time you look at test.out
>> the FIRST return of setmode is the same as the argument of setmode,
>> i.e. O_TEXT. Thus in all your runs the file was initially TEXT,
>> although the output appears to be binary.
>> At any rate setmode had no effect.
>>
>> Next I duplicated your experiments (standard g++ in b20.1 only).
>> I don't trust editors to look at CR in files and used "od -c test.out".
>> That shows an extra  ^M on all lines compared to your output.
>> On a binary mounted system test.out is initially binary (as it should),
>> but the output is the same.  Also setmode works for stdout.
>>
>> Next I wrote a similar test in C. There setmode works as expected.
>>
>> I am wondering what you see if you look at your files with od -c,
>> and if you agree that setmode works in a C program
>> (that would point to a C++ error (?))
>
>I verified the results of `vi' (`vim' not `elvis')
>with the results of `od' before I sent the original message.
>I included the results from `vi' in my original message
>because they are easier to read.
>I thought it would be obvious from the `test.dos' and `test.cyg' output
>that `vi' accurately represented the actual contents of the file.
>
>Do `vi' and `od' give you different results on your system?
>
>E. Robert Tisdale <edwin@netwood.net>
>


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

Re: setmode (long)

[E. Robert Tisdale]

Pierre A. Humblet wrote:

> I had a second look (b20.1 on win95) at your problem
> and it's not what I thought initially,
> i.e. a basic problem with the cygwin layer in b20.1,
> which tends to open too many files as binary.
>
> In your output, each time you look at test.out
> the FIRST return of setmode is the same as the argument of setmode,
> i.e. O_TEXT. Thus in all your runs the file was initially TEXT,
> although the output appears to be binary.
> At any rate setmode had no effect.
>
> Next I duplicated your experiments (standard g++ in b20.1 only).
> I don't trust editors to look at CR in files and used "od -c test.out".
> That shows an extra  ^M on all lines compared to your output.
> On a binary mounted system test.out is initially binary (as it should),
> but the output is the same.  Also setmode works for stdout.
>
> Next I wrote a similar test in C. There setmode works as expected.
>
> I am wondering what you see if you look at your files with od -c,
> and if you agree that setmode works in a C program
> (that would point to a C++ error (?))

I verified the results of `vi' (`vim' not `elvis')
with the results of `od' before I sent the original message.
I included the results from `vi' in my original message
because they are easier to read.
I thought it would be obvious from the `test.dos' and `test.cyg' output
that `vi' accurately represented the actual contents of the file.

Do `vi' and `od' give you different results on your system?

E. Robert Tisdale <edwin@netwood.net>


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

Re: setmode (long)

[Mumit Khan]

On Thu, 25 Feb 1999, E. Robert Tisdale wrote:

> 
> Does anyone know whether the DJGPP compiler
> has been fixed and tested yet?
> 

You can always try it.

I did run your code using mingw32 and MSVC and it gives the same output.

Mumit


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

Re: setmode (long)

[DJ Delorie]

> Does anyone know whether the DJGPP compiler has been fixed and
> tested yet?

I don't know of any fixes relevent to this, but you might try using
egcs for djgpp instead of gcc - it has a different C++ library.

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

Re: setmode (long)

[E. Robert Tisdale]

Christopher Faylor wrote:

> That's right in older Cygwin's
> setting the mode to TEXT didn't necessarily change the mode.
> This should be fixed in the snapshots.
>
> We have gone around and around on this behavior in the developers list
> but I think that the current implementation is correct.

What do you mean by "older Cygwin's"?
I downloaded Beta 20.1 and installed it.

Do you mean that the problem has already been fixed in the snapshots?
Has anyone actually tested (test'd) the snapshots
to determine whether this behavior still persists or not?

Should I download the latest snapshot
and use it to compile my application programs?
Or should I wait until the next release
before upgrading my compiler?

Does anyone know whether the DJGPP compiler
has been fixed and tested yet?

Thanks in advance, E. Robert Tisdale <edwin@netwood.net>



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

Re: setmode (long)

[Christopher Faylor]

On Tue, Feb 23, 1999 at 10:19:47PM -0800, E. Robert Tisdale wrote:
>...shows that test.out was opened in binary mode
>and setmode didn't switch to text mode.

That's right in older Cygwin's setting the mode to TEXT didn't
necessarily change the mode.  This should be fixed in the
snapshots.

We have gone around and around on this behavior in the developers
list but I think that the current implementation is correct.

cgf

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

setmode (long)

[E. Robert Tisdale]

I have written an application in C++ which is supposed to compile
and run on any platform including UNIX, DOS and Windows 95/98/NT.
It reads and writes text as well as binary data from files and
standard input and output.  It uses the line feed (newline) character
to mark the end of a line and the carriage return line feed sequence
to mark the end of a paragraph.  It reads and writes text files
in binary mode and converts \r\n to \n on input and \n to \r\n
on output for DOS (and Windows 95/98/NT) systems so that the user
can read, edit and print them using native tools.

On DOS and Windows 95/98/NT systems, the C preprocessor includes code
which uses setmode to change the default I/O mode from text to binary.
This worked just fine with older versions of DJGPP on DOS
but I have just downloaded and installed the most recent versions
of DJGPP, Cygwin and mingw32 and I am experiencing some problems.
I wrote a short program, `test.cc', to help illustrate them.
----------------------------------------------------------------------

// test.cc

#include<fstream.h>
#include<io.h>
#include<fcntl.h>

int
main() {
  int   oldmode = 0;
  cout << "default mode:\n";
  cout << "  0 carriage returns\n";
  cout << "  1 carriage returns\r\n";
  cout << "  2 carriage returns\r\r\n";
  cout << "  3 carriage returns\r\r\r\n";
  oldmode = setmode(1, O_TEXT);
  cout << hex << oldmode <<
    " = setmode(1, " << hex << O_TEXT   << "):\n";
  cout << "  0 carriage returns\n";
  cout << "  1 carriage returns\r\n";
  cout << "  2 carriage returns\r\r\n";
  cout << "  3 carriage returns\r\r\r\n";
  oldmode = setmode(1, O_BINARY);
  cout << hex << oldmode <<
    " = setmode(1, " << hex << O_BINARY << "):\n";
  cout << "  0 carriage returns\n";
  cout << "  1 carriage returns\r\n";
  cout << "  2 carriage returns\r\r\n";
  cout << "  3 carriage returns\r\r\r\n";
  oldmode = setmode(1, O_TEXT);
  cout << hex << oldmode <<
    " = setmode(1, " << hex << O_TEXT   << "):\n";
  cout << "  0 carriage returns\n";
  cout << "  1 carriage returns\r\n";
  cout << "  2 carriage returns\r\r\n";
  cout << "  3 carriage returns\r\r\r\n";

  ofstream      test_out("test.out", ios::out);
  test_out << "default mode:\n";
  test_out << "  0 carriage returns\n";
  test_out << "  1 carriage returns\r\n";
  test_out << "  2 carriage returns\r\r\n";
  test_out << "  3 carriage returns\r\r\r\n";
  oldmode = setmode((test_out.rdbuf())->fd(), O_TEXT);
  test_out << hex << oldmode <<
    " = setmode((test_out.rdbuf())->fd(), " << hex << O_TEXT   << "):\n";
  test_out << "  0 carriage returns\n";
  test_out << "  1 carriage returns\r\n";
  test_out << "  2 carriage returns\r\r\n";
  test_out << "  3 carriage returns\r\r\r\n";
  oldmode = setmode((test_out.rdbuf())->fd(), O_BINARY);
  test_out << hex << oldmode <<
    " = setmode((test_out.rdbuf())->fd(), " << hex << O_BINARY << "):\n";
  test_out << "  0 carriage returns\n";
  test_out << "  1 carriage returns\r\n";
  test_out << "  2 carriage returns\r\r\n";
  test_out << "  3 carriage returns\r\r\r\n";
  oldmode = setmode((test_out.rdbuf())->fd(), O_TEXT);
  test_out << hex << oldmode <<
    " = setmode((test_out.rdbuf())->fd(), " << hex << O_TEXT   << "):\n";
  test_out << "  0 carriage returns\n";
  test_out << "  1 carriage returns\r\n";
  test_out << "  2 carriage returns\r\r\n";
  test_out << "  3 carriage returns\r\r\r\n";
  return 0;
  }
----------------------------------------------------------------------

I compiled under Windows 98 using DJGPP and a DOS shell (MS-DOS Prompt)

        >gxx -v -w -O2 -o test test.cc -lgpp

and I ran the test program

        >.\test > test.dos

I started a Cygwin-b20 bash shell and examined the results:

        $ vi test.dos
        default mode:^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M
        8 = setmode(1, 8):^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M
        8 = setmode(1, 4):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        4 = setmode(1, 8):^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M

appears to be correct but

        $ vi test.out
        default mode:
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        8 = setmode((test_out.rdbuf())->fd(), 8):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        8 = setmode((test_out.rdbuf())->fd(), 4):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        4 = setmode((test_out.rdbuf())->fd(), 8):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M

shows that test.out was opened in binary mode
and setmode didn't switch to text mode.

----------------------------------------------------------------------

I compiled under Windows 98 using EGCS Cygwin-b20 and a bash shell

        $ g++ -v -Wall -O2 -o test test.cc

ran the test program

        $ ./test > test.cyg

and examined the results:

        $ vi test.cyg
        default mode:^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M
        20000 = setmode(1, 20000):^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M
        20000 = setmode(1, 10000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        10000 = setmode(1, 20000):^M
          0 carriage returns^M
          1 carriage returns^M^M
          2 carriage returns^M^M^M
          3 carriage returns^M^M^M^M

appears to be correct but

        $ vi test.out
        default mode:
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        20000 = setmode((test_out.rdbuf())->fd(), 20000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        20000 = setmode((test_out.rdbuf())->fd(), 10000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        10000 = setmode((test_out.rdbuf())->fd(), 20000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M

shows that test.out was opened in binary mode
and setmode didn't switch to text mode.

----------------------------------------------------------------------

I re-compiled under Windows 98 using EGCS Cygwin-b20 with mingw32

        $ g++ -L/mingw32/lib -L/mingw32/i386-mingw32/lib \
        -L/mingw32/lib/gcc-lib/i386-mingw32/egcs-2.91.60 \
        -v -Wall -O2 -mno-cygwin -o test test.cc -lstdc++ -liberty

and ran the test program using and a DOS shell (MS-DOS Prompt)

        >.\test > test.win

I used the Cygwin-b20 bash shell to examine the results:

        $ vi test.win
        default mode:
          0 carriage returns
          1 carriage returns
          2 carriage returns
          3 carriage returns
        4000 = setmode(1, 4000):
          0 carriage returns
          1 carriage returns
          2 carriage returns
          3 carriage returns
        4000 = setmode(1, 8000):
          0 carriage returns
          1 carriage returns
          2 carriage returns
          3 carriage returns
        8000 = setmode(1, 4000):
          0 carriage returns
          1 carriage returns
          2 carriage returns
          3 carriage returns

contains no carriage returns and

       $ vi test.out
        default mode:
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        4000 = setmode((test_out.rdbuf())->fd(), 4000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        4000 = setmode((test_out.rdbuf())->fd(), 8000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M
        8000 = setmode((test_out.rdbuf())->fd(), 4000):
          0 carriage returns
          1 carriage returns^M
          2 carriage returns^M^M
          3 carriage returns^M^M^M

shows that test.out was opened in binary mode
and setmode didn't switch to text mode.

----------------------------------------------------------------------

I didn't change any of the default settings when I installed Cygwin.
I didn't mount any file systems as binary only or define binmode.
I've read the FAQs and searched the mailing list archives.

It appears to me that there are still very serious problems
with text and binary I/O in DJGPP, Cygwin-b20 and mingw32
using Cygwin-b20 bash and MS-DOS Prompt under Windows 98.

Also, all the information regarding text and binary I/O
seems to be scattered across many different documents.
I think it would help me and other portable application
programmers if someone could put it all together
in one place with expicit references to the specific
operating system, compiler and shell to which it applies.

Thanks in advance, E. Robert Tisdale <edwin@netwood.net>

NOTE:   My editor, `vi', displays a carriage return as ^M
        but the line feed at the end of the line is invisible.
        My DOS shell is C:\WINDOWS\COMMAND.COM



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