> First, you'd probably like to write some unit tests (well, > I guess that would be impossible, since any test of > this function would not be a "unit test" by the definition > proposed here), to make sure you don't break the existing > behavior. > > Refactoring to a lot of little functions is not an option > here -- that would break thousands and thousands of > applications.
If by "Refactoring to a lot of little functions" you're thinking that we'd change the method signature, then you're right. We'd be breaking the existing API, which is a no-no.
However, as developer/bug-fixer, what is to stop us from extracting the buggy piece of code inside of CreateFile() into it's own function or functions, that we could then unit test more easily? (And if the reason in this example is I/O performance, does that mean that this approach to refactoring/writing tests would NEVER work?)