Get the latest tech news

I thought I found a bug

So I was working on improving a DOS emulator, when I found that something seemingly trivial wasn’t working right when COMMAND.COM was asked to do the following: echo AB> foo.txt echo CD>> foo.txt Instead of ABCD, foo.txt contained ABBC. I verified that yes, the right data was being passed to fwrite(), with the big caveat that what COMMAND.COM was doing wasn’t quite as straightforward as one might think: - Open foo.txt - Write ‘AB’ - Close foo.txt - Open foo.txt - Seek one byte backward from the end of the file - Read one byte - Write ‘CD’ - Close foo.txt The reason for the complexity is that COMMAND.COM tries to deal with a case that the file ends with a Ctrl-Z character (which wasn’t the case for me), and if so, the Ctrl-Z needs to be deleted.

It is obvious that it would not be rocket science for the C library to keep a record of whether the most recent I/O was a read or a write, and perform the appropriate flush or seek when switching directions. A change of input/output direction on an update file is only allowed following a fsetpos, fseek, rewind, or fflush operation, since these are precisely the functionswhich assure that the I/O buffer has been flushed. Sure, there was no fsetpos() yet (an ANSI C invention), and the text is oddly missing any mention of fflush(), even though flushing almost certainly made it OK to switch from writing to reading even then.

Get the Android app