If it's one of the DOS-based versions, you'll find junk in your files. That is, suppose your savefile was 512 bytes long, however it actually wrote 510 bytes starting at an offset of 2; the first two bytes might be, say, 0x1234, rather than the 0x0000 that anyone would reasonably expect.
There are two ways to deal with this: the most straightforward way would be to use an NT-based Windows - NT4, Win2k, XP &c.
But if you game won't run on NT - that's the case for many as they write directly to the video card and sound card - an acceptable solution would be to write a tool that fills up all the free space on your filesystem with zeroes.
That's what I myself actually did for Movie Magic, as I was using Mac OS 8.1 at the time - long before we had Mac OS X.
And that right there was my most-significant competitive advantage; as far as I have ever been able to tell, no one else has ever figured out to do that.
I am willing to spill the beans as nowadays everyone uses at least allegedly "secure" operating systems.
Finally you have to be concerned about junk returned by the system memory allocator. Even in *NIX, malloc doesn't initialize its buffers, however the kernel initializes memory to zero when you grow the process memory with setbrk.
Loosely speaking, when malloc runs out of memory, it asks the kernel for more memory by increasing the break. The break is the boundary between mapped memory and unmapped memory; it grows upward. The stack starts towards the top of the address space and grows downward. Between the two is unmapped memory; while strictly speaking it is addressable to actually do so will cause a segvio.
On a secure system, decrementing the stack pointer or incrementing the break will result in zero-filled memory.
On MS-DOS, Windows 98, Mac OS 8 &c. that memory will be full of junk.
I don't know how I'd do this on Windows but on the Classic Mac OS it was not hard at all to patch the system, so I'd hack the Memory Manager to always initializes the buffers it returns.