what's the differences between r and rb in fopen

Question

I tried using fopen in C, the second parameter is the open mode. The two modes "r" and "rb" tend to confuse me a lot. It seems they are the same. But sometimes it is better to use "rb". So, why does "r" exist? Explain it to me in detail or with examples. Thank You.

Solution 1

You should use "r" for opening text files. Different operating systems have slightly different ways of storing text, and this will perform the correct translations so that you don't need to know about the idiosyncracies of the local operating system. For example, you will know that newlines will always appear as a simple "\n", regardless of where the code runs.

You should use "rb" if you're opening non-text files, because in this case, the translations are not appropriate.

Solution 2

On Linux, and Unix in general, "r" and "rb" are the same. More specifically, a FILE pointer obtained by fopen()ing a file in in text mode and in binary mode behaves the same way on Unixes. On windows, and in general, on systems that use more than one character to represent "newlines", a file opened in text mode behaves as if all those characters are just one character, '\n'.

If you want to portably read/write text files on any system, use "r", and "w" in fopen(). That will guarantee that the files are written and read properly. If you are opening a binary file, use "rb" and "wb", so that an unfortunate newline-translation doesn't mess your data.

Note that a consequence of the underlying system doing the newline translation for you is that you can't determine the number of bytes you can read from a file using fseek(file, 0, SEEK_END).

Finally, see What's the difference between text and binary I/O? on comp.lang.c FAQs.

Solution 3

use "rb" to open a binary file. Then the bytes of the file won't be encoded when you read them

Solution 4

• "r" is the same as "rt" for Translated mode
• "rb" is non-translated mode.

This makes a difference on Windows, at least. See that link for details.

Solution 5

On most POSIX systems, it is ignored. But, check your system to be sure.

XNU

The mode string can also include the letter 'b' either as last character or as a character between the characters in any of the two-character strings described above. This is strictly for compatibility with ISO/IEC 9899:1990 ('ISO C90') and has no effect; the 'b' is ignored.

Linux

The mode string can also include the letter 'b' either as a last character or as a character between the characters in any of the two- character strings described above. This is strictly for compatibility with C89 and has no effect; the 'b' is ignored on all POSIX conforming systems, including Linux. (Other systems may treat text files and binary files differently, and adding the 'b' may be a good idea if you do I/O to a binary file and expect that your program may be ported to non-UNIX environments.)

View more solutions

Comments

[C. K. Young]

This is platform-dependent. On Unix, text-mode does nothing special, so it still won't handle \r\n as \n.

[Alok Singhal]

The idea is that "r" will correctly open a "text file" on the same system. If you're opening a Windows text file on Linux with "r", you have to take care of different line ending conventions yourself, of course.

[Alok Singhal]

If you open a file written in Windows on a linux system, you will see the behavior. You need to convert the file to a unix text file. You can easily do it with a program called dos2unix, or in vim, after opening a file, type, :se ff=unix, hit return, and then save.

[caf]

Aye. As Alok says, "r" is for opening text files as defined by the local custom - ie opening Linux text files on Linux, Windows text files on Windows and OS/390 text files on OS/390. If you're going to move text files between PCs, it's up to you to translate them to the native format.

[StevenWang]

@caf, all my file and operations r all window-typed...you can try my plus example.....

[caf]

If you want help with that specific example, you'll have to post the code that has the problem (preferably, as a new question).

[Alok Singhal]

@Macroideal: Shouldn't happen. If I were to guess, maybe that's because you tried to determine file size using fseek, and then ignored the return value from fread? I am just guessing here. See my answer to your question and stackoverflow.com/questions/260235/… for details.

[SF.]

...try loading a picture using plain 'r' and displaying it. The corruption resulting from conversion should make the need for 'rb' apparent...

[Charlie Parker]

what does "translations" mean in this context?

[caf]

@CharlieParker: It means the necessary transformations to map between the system's conventions for storing plain text files and the C definition of a text stream, which is "an ordered sequence of characters composed into lines, each line consisting of zero or more characters plus a terminating new-line character.". An example is that on MacOS Classic, the convention for text files was lines of characters terminated with a carriage-return. A good C implementation on this OS would, for text streams, map carriage-return characters into new-line characters on input, and the reverse on output.

[Gabriel Schulhof]

Not to mention EOF. If you open with "r" on Windows and there's a 0x1a somewhere in the file, it will say it's EOF and won't read the rest of the file.

[Gherman]

I think there may be caveats in this way of thinking. The system executing the program may be Linux but the file being opened may have been created elsewhere. Imagine you are writing a server program code. The server itself may run Linux but end users uploading the files to the server may be using Windows. In this case the files may contain \r\n or \r instead of \n. In the end it is the contents of the file itself that make the difference, not exactly the system.