fopen in text mode ('rt') giving wierd results

I am currently using version 2013a on Windows but I have received a project from our old Linux server. There is a line in it which opens a binary file like this:

fp = fopen(file, 'rt', 'l');
data = fread(fp, inf, 'float32');

When I use this command on Linux I get the expected data out of the file. When I use the same command on Windows I get one fewer number and everything after the nth entry is bad until the mth entry. This is very repeatable for a given file. Does the text mode force Matlab to look for ascii new lines even in a binary file? If I change the fopen command on Windows to this:

fp = fopen(file, 'r', 'l');

The problem goes away. I am hoping this is just something that this is just a bug with our old code that was never tested on Windows.

[Bruno Pop-Stefanov]

As you pointed out, the 'rt' permission argument opens the file for reading in text mode. On Windows machines, the carriage return character \r is removed when reading text in.

Is the file binary? If yes, does the file contain only numbers? If yes, what number is missing?

13 is the ASCII code for carriage return. I would assume that opening the file for reading in text mode mistakes the number 13 for a carriage return, or that one of the number you read in contains the byte 13 (out of the four bytes a float is made of).

I believe that 't' has no effect on UNIX machines, so the question is: Why are you opening the file in text mode?

[Bruno Pop-Stefanov]

This is actually the expected behavior (not a bug):

http://www.mathworks.com/matlabcentral/answers/92494-why-are-some-bytes-skipped-from-input-when-i-try-to-use-fread-function-to-read-a-file-that-is-opened

Answer 1

[Matt]

As Bruno Pop-Stefanov pointed out the problem is opening a binary file in text mode on Windows. The behavior seen was expected given the contents of the file. The solution of opening binary files without the 't' is correct.