F**K me! One thing you never ever do, is change the variables related to a loop construct whilst it's executing. I learned this when I was 16 years old at school in my computer studies O'level.

And you certainly don't allow threads to interfere with other variables unless you've got some sort of gating mechanisms in place such as semaphores.

This is just p**s poor bad design. Where's the design diagrams and documentation showing how threads interact with each other?

Looks like they haven't properly defined or documented the interfaces between program elements/modules.

Yes, it is a difficult thing to identify with a test tool, but this comes back to poor design and poor design documentation, either that or the developer didn't read the design documentation fully.

I thought Microsoft developers and designers were supposed to be better than this?

Seems odd that so many people can find ways to expose bugs in IE but MS' code tools can't. Maybe relying on build code tools is the wrong approach and they should look at how those who expose their bugs are testing for them.

Call it what they will, it is still bad practice, and the fault of the developer (out of ignorance, as Tim Brown suggests) not checking the environment properly. Giving it a spiffy sounding name and acronym only legitimizes the practice as a common issue within the environment, when in fact it's just incompentence.

It's like giving a fancy name to, say, forgetting to remove one from the full count of items in an array, when iterating from zero:

for (int i = 0; i <= myArray.Size(); i++)

myArray[i]->foo(); // will point to hell when i = Size

It is not an issue inherent in the platform, language, or framework; it is not something that we must "warn against", as if it were some abstract creeping evil lurking in the shadows of the machine. A competent developer understands the boundaries of the arrays with which he is working, and set his control variables accordingly.

But just for the hell of it, let's give it a cutesy name: Final-Out-Of-Band-Array-Register. Remember kids, watch out for those nasty FOOBAR's, they just sneak up on you like the dickens!

-dZ.

The armchair coders are out in force. Wow, you guys must all be really shit-hot.

@Eddie Johnson: Microsoft's KB and MSDN are fantastic, I don't do Windows development any more but I wish the docs for what I do code for now were of the same quality. It definitely beats man-pages anyway

@DZJay and Tim Brown: Developers come and go, chances are this code was written years ago, by a developer who has left, before everybody did fancy UML diagrams (which are largely useless anyway with the exception of sequence diagrams). There is bad code everywhere... I know there is bad code is some frameworks I work with, but it's not that easy to just go fix stuff. Just ask your manager, and product owners and customers.

@Rotacyclic: You've never written software in a commercial environment have you? (and doing web pages doesn't count)

I remember years ago scratching my head over some Data Access Objects code I had written, checked, rechecked that I was using the methods correctly as stated in the documentation, still couldn't get the bloody code to work properly..only one conclusion left..the MS documentation on the objects was wrong...and it was.

That's all I needed, I expected my code to be wrong, I didn't expect the objects not to work properly, and I didn't expect the f***ng documentation for the software developers to be wrong either!

So I concluded that there are two independent teams ( not unreasonably so): the software development teams constructing the objects and the documentation team which are given a requirements document of what the objects should do, the documentation team write their docs and there's no amalgamation of the two at the end to update the documentation to reflect reality.

How the f**k can you get the developer's documentation wrong? That was I think my realisation that Microsoft - despite being the largest software developer in the world - just can't get the basics right.

Then I recalled back to something a former manager of mine had said to me in a previous company, when estimating project timescales, calculate how long you think it should take and then double it because you're dealing with Microsoft. He wasn't wrong.

to catch that one you'd need pretty sophisticated fuzzing tools. Or software developers who knew what they were doing.

That's not a TOCTOU, it's just a fuckup.

@James,

Wow, I'd hate to work on the same projects you have if this sort of thing is so commonplace. In my experience, as stated, this is just bad design and poor understanding of the system in which the developer was working.

The possibility that a developer left the company and now everybody else is stuck with a mess of abstruse code, does not excuse it; and in fact it says much about the development and documentation practices of the organization: again, bad design and incompetence.

This may be very common in some places, but trust me when I say that it is definitely not an inherent aspect of software development, and it does not occur everywhere as a rule.

-dZ.

This is simple to understand - MS doesn't know what it is doing, simple really. This practice is rather common. The underline problem:

1. The design team doesn't fully understand what they want. They gave a fuzzy outline and objectives, without giving all the requirements to the team do the coding.

2. The coders don't know what they are doing. They may do their best based on what they understood of the partial requirement. Plus some of those so called "developers" really cannot code anything there days.

3. There is no/little documentation, and the test team doesn't really test properly.

To "fix" the problem, the design/review team must know what they want and what they look for. This requires the team to understand the technology, environment, and the will to do some work, rather than sit there and saying "I want these, these and that, now write it".

@Mike,

True, it is not a threading issue (I never thought it was). Technically, reentrancy bugs can be solved with semaphores, but it would be a much better solution to actually, well, design the damn thing appropriately to not have side effects.

-dZ.

It is a fairly obscure bug, but worrying in that a) it exists, and has done for gods-know-how-long, and b) that they managed to miss it with their testing and QA procedures.

Also, Abstruse - that's now my word of the day!