2

I used std::cout << (char)0xA in my C++ code.
Then, I wrote to the console myProgram.exe > file.txt.
Next, I opened file.txt with A HEX editor and I found 0D 0A instead of 0A.

IDK why this happened. Please, help.

HEX Editor screenshot (look at 0x82 and 0x19B)

phuclv
  • 37,963
  • 15
  • 156
  • 475
jcdkiki_rus
  • 31
  • 1
  • 7
  • One some platforms, the canonical end-of-line is `0D 0A` for a `'\n'`. – Eljay Mar 23 '20 at 22:23
  • Already resolved here : https://stackoverflow.com/questions/12747722/what-is-the-difference-between-a-line-feed-and-a-carriage-return – Landstalker Mar 23 '20 at 22:25

2 Answers2

4

The C and C++ Standards both specify that when a stream is open in text mode, sending a \n to it will do whatever action is necessary on the target system to advance the file to the next line. On a Unix system, that simply means outputting a \n to a file. On some record-based systems, it means flushing the current line-output record and advancing to the next one. On MS-DOS and Windows, it means sending both a \r and \n to the stream.

Historically, sending a \r to a teletype would reset the carriage to the left edge, and sending a \n would advance the paper. Someone realized that while the ability to reset the carriage without advancing paper was useful, having \n advance the paper without resetting the carriage was far less so, and thus some devices will respond to \n by advancing to the start of the next line. MS-DOS, however, opted to have files stored in a way that would produce meaningful output if sent directly to a printer where \n would advance to the current location on the next line, and one would have to send both \r and \n if one wanted to go to the start of the next line.

supercat
  • 77,689
  • 9
  • 166
  • 211
  • Thanks. I`ll use ofstream next time. – jcdkiki_rus Mar 23 '20 at 22:26
  • Should be the same result as long as you are on the same OS. – drescherjm Mar 23 '20 at 22:31
  • MS-DOS inherited the behavior from CP/M. ASCII at one time required `0D 0A`, but eventually made the `0D` implied if not present. Apple (AppleDOS, Mac OS) didn't get the memo, and went with `0D` as end-of-line until OS X. – Eljay Mar 23 '20 at 22:32
  • I opened file.txt with std::ios::binary and it works fine! – jcdkiki_rus Mar 23 '20 at 22:34
  • That is correct, in text mode you get the behavior in binary you don't – drescherjm Mar 23 '20 at 22:37
  • @Eljay: Most printers were configurable to treat 0x0D as a command to reset the carriage and advance paper, but would always treat 0x0A as a command to advance paper without resetting the carriage without a configuration option to do otherwise. – supercat Mar 23 '20 at 22:39
  • @supercat • plus configuring the number of NUL characters to send after a CRLF so the carriage has enough time to actually return to left side. Good times. – Eljay Mar 24 '20 at 02:54
3

Welcome to the magic of end of lines across OS!

The C language originally was developped for Unix systems where the end of line was marked by the single '\n' (ASCII code 0x0A) character.

When it was ported to other systems, it was decided that seen from the programmer an end of line will only be a '\n', and that the drivers and the standard library would convert it to the appropriate line ending when the file would be opened in text mode.

That convention was later keeped in C++.

As Windows uses "\r\n" as an end of line marker, the standard library convert any '\n' to the pair "\r\n" (ASCII codes 0x0D and 0x0A).

Serge Ballesta
  • 143,923
  • 11
  • 122
  • 252