tags:

views:

2192

answers:

4

What translation occurs when writing to a file that was opened in text mode that does not occur in binary mode? Specifically in MS Visual C.

unsigned char buffer[256];
for (int i = 0; i < 256; i++) buffer[i]=i;
int size  = 1;
int count = 256;

Binary mode:

FILE *fp_binary = fopen(filename, "wb");
fwrite(buffer, size, count, fp_binary);

Versus text mode:

FILE *fp_text = fopen(filename, "wt");
fwrite(buffer, size, count, fp_text);
+11  A: 

In text mode, a newline "\n" may be converted to a carriage return + newline "\r\n"

Usually you'll want to open in binary mode. Trying to read any binary data in text mode won't work, it will be corrupted. You can read text ok in binary mode though - it just won't do automatic translations of "\n" to "\r\n".

See fopen

MrZebra
For reading, the translation works the opposite of what you describe - converting "\r\n" to "\n".
Mark Ransom
+4  A: 

Additionally, when you fopen a file with "rt" the input is terminated on a Crtl-Z character.

Shane MacLaughlin
True - I make my own file formats start with something like "my-file-type^Z", then if you "type"/"cat" it from the command line, it just gives you the file's "magic numbers" and stops instead of spewing binary to your terminal.
MrZebra
A: 

We had an interesting problem with opening files in text mode where the files had a mixture of line ending characters:

1\n\r
2\n\r
3\n
4\n\r
5\n\r

Our requirement is that we can store our current position in the file (we used fgetpos), close the file and then later to reopen the file and seek to that position (we used fsetpos).

However, where a file has mixtures of line endings then this process failed to seek to the actual same position. In our case (our tool parses C++), we were re-reading parts of the file we'd already seen.

Go with binary - then you can control exactly what is read and written from the file.

Richard Corden
+6  A: 

I believe that most platforms will ignore the "t" option or the "text-mode" option when dealing with streams. On windows, however, this is not the case. If you take a look at the description of the fopen() function at: MSDN, you will see that specifying the "t" option will have the following effect:

  • carriage returns ('\n') will be translated to '\r\n" sequences on output
  • carriage return/line feed sequences will be translated to carriage returns on input.
  • If the file is opened in append mode, the end of the file will be examined for a ctrl-z character (character 26) and that character removed, if possible. It will also interpret the presence of that character as being the end of file. This is an unfortunate holdover from the days of CPM (something about the sins of the parents being visited upon their children up to the 3rd or 4th generation). Contrary to previously stated opinion, the ctrl-z character will not be appended.
Jon Trauntvein
carriage return is actually '\r', '\n' is line feed.
Christoffer Hammarström