getc() says $1A = EOF! Wtf?

I've just spent a few hours trying to work out why my level editor wasn't loading certain level files properly. After a certain point, everything byte starts returning EOF, -1.

Turns out it was the $1A character tripping it up. I did a bit of searching around and all I could find was one thread by another person with the same problem and some source code with a comment about how $1A is meant to mean end of file in the DOS instruction set or something. Strange.

Can anyone tell my why this happens, and how I can get around it?

Cheers.

AFAIK EOF should not cause a problem. EOF is not recorded in the file but in the file system. EOF in DOS was placed in the last cluster of the file. So when the next FAT cluster indicated EOF, DOS stopped following the cluster chain. In other words EOF is encoded below the level of the actual file object. It is part of the file cluster chain.

But you probably want to open the file in binary mode so no interpretation is done on the binary data in the file.

Thankyou! Switched "r" to "rb" and it works beautifully. I hadn't realised there was a separate binary mode. Amazing what difference one character can make.

Indeed, MS-DOS distinguishes between text mode and binary mode. One of the "features" of text mode is that when you're reading a file and you get the '\x1A' character, that signifies end of file.