Tricky cout with 0x0A value

[Jean-Gael GRICOURT]

I am trying to use ostringstream in binary mode. Why the value (0x0A)
is automatically replaced by (0x0D,0x0A) in the output ? Is there a
workaround to this issue ?

-------- my snippet code -------

#include <iostream>
#include <sstream>
using namespace std;

int main(int argc, char **argv) {
char buf[512];
ostringstream oss (ostringstream:ut | ostringstream::binary);

buf[0] = 0x0A;
oss.write(buf, 1);
cout << oss.str();
return 0;
}

-------- output -------
a.exe > data.txt
A binary dump of data.txt gives: 0D 0A and not 0A as expected.

 

[Martijn Lievaart]

I am trying to use ostringstream in binary mode. Why the value (0x0A)
is automatically replaced by (0x0D,0x0A) in the output ? Is there a
workaround to this issue ?

-------- my snippet code -------

#include <iostream>
#include <sstream>
using namespace std;

int main(int argc, char **argv) {
char buf[512];
ostringstream oss (ostringstream:ut | ostringstream::binary);

buf[0] = 0x0A;
oss.write(buf, 1);
cout << oss.str();
return 0;
}

-------- output -------
a.exe > data.txt
A binary dump of data.txt gives: 0D 0A and not 0A as expected.

The stringstream is binary, but cout is not. So you output the LF to
cout which translates it to CRLF. BTW, why not us '\n' instead of 0x0A?

HTH,
M4

 

[David Harmon]

oss.write(buf, 1);
cout << oss.str();

-------- output -------
a.exe > data.txt
A binary dump of data.txt gives: 0D 0A and not 0A as expected.

The binary ostringstream is probably fine, but cout is text mode (and
there is no standard portable way to change it to binary) and can be
expected to mangle 0x0A just as you observed. You probably need to
create a binary ofstream to do your output.

 

[David Harmon]

BTW, why not us '\n' instead of 0x0A?

'\n' is the portable way to represent whatever your platform uses for a
newline separator (in text files.)

0x0A is a way to represent that you may expect to find in a binary file
regardless of they way your platform handles text lines.

In case they might not be the same, the latter is the one he wants.

 

[DarkSpy]

at 1 Feb 2004 12:56:02 -0800 , (e-mail address removed) (Jean-Gael GRICOURT)
wrote:

-------- output -------
a.exe > data.txt
A binary dump of data.txt gives: 0D 0A and not 0A as expected.

this is windows pipeline's bug, not program's problem
if u create a file on unix system, that is ok.

[comp.lang.c++]
[comp.lang.c++.moderated]
DarkSpy, A C++ MadDog.

 

[Martijn Lievaart]

'\n' is the portable way to represent whatever your platform uses for a
newline separator (in text files.)

0x0A is a way to represent that you may expect to find in a binary file
regardless of they way your platform handles text lines.

In case they might not be the same, the latter is the one he wants.

Yes, absolutely. Forget I ever said it, it is most probably just the
problem condensed to the trouble value.

M4

 

[Jean-Gael GRICOURT]

Thank you all for your prompt replies. I finally found out what was
wrong. "Cout" involves an OS dependent IO operation. On the Win32
plateform it has the side effect I've described in my previous post.
So I added the necessary code to change this default behaviour to make
sure that the output will be binary:

#ifdef _WIN32
#include <io.h>
#include <fcntl.h>
#endif

[...]

#ifdef _WIN32
_setmode(_fileno(stdin), _O_BINARY);
_setmode(_fileno(stdout), _O_BINARY);
#endif

end of the story ...