Programming Frustration Rants

1 points by palish ↗ HN
I was originally going to post one specific rant, but to make this thread more constructive, how about we all share some programming frustrations we've run into? It could be interesting. Feel free to be as technical, and as inflammatory, as you want. Use this thread as an outlet for your frustration with other people's technical fumbles.

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.

3 comments

[ 2.7 ms ] story [ 17.2 ms ] thread
Why would a game developer need to process 4GB in one file? Why not split it in more files?

Also, assuming you don't have experience with OS X why should I believe OS X wouldn't cause you other kind of frustrating problems?

because, you know, OS X is kinda ... cool, just as git seems to be cool nowadays.

But I agree, it's quite easy to declare it an epic fail.

Why not split it in more files?

Why overcomplicate code? 4GB is a completely arbitrary restriction.

why should I believe OS X wouldn't cause you other kind of frustrating problems?

OS X does have its own set of frustrations, but theirs seem to be easier to work around, in my limited experience. Also, they aren't usually complete roadblocks, like the Windows Large File Support problem.