Here's mine. Apparently you can't use the C file interface (fopen, etc) with large (4GB or greater) files on Windows, because of a bug in the way Microsoft implemented the C standard library ( http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/2204ecc0-d2ad-476c-8b20-362948da8c2c/ ). Quoth Microsoft:

"The problem is caused by an internal check in fopen, which attempts to seek one byte prior of the end of the file, and read the last byte. To do this seek, fopen uses _lseek_nolock, which in turn calls SetFilePointer with a lDistanceToMove = -1, lpDistanceToMoveHigh = NULL and dwMoveMethod = FILE_END. That appears not to work with 64bit file pointers, so I'm inclined to call it a bug in the standard library."

The Microsoft rep then pastes the line of code that breaks large file support -- and also shows how it could have been fixed. In other words, rather than fixing the bug, he shows how the bug could have been fixed.

In my opinion, that is bullshit. The C file interface is designed to work with large files. That's the point of the "fpos_t" type, right? It's 64 bits wide, at least on Windows. But because of the bug, the largest file the C standard interface can work with is (4GB - 1) bytes.

The C functions "ftell" and "fseek" use 32-bit file position values, so they can't work with large files. But so what? "fgetpos" and "fsetpos" do the same thing, and they use 64-bit position values. There's no reason not to implement those functions correctly.

This is 2009. It is an epic fail for any operating system to not properly implement large file support for the standard C file API. I'm a game developer, so I'm stuck on Windows. If it weren't for that, I'd have moved on to greener pastures (OS X?) long ago.

Oh well, I'll use the CreateFile/SetFilePointer/etc functions on Windows.