Superstition

Sometimes, just sometimes the compiler is actually right.

The problem is, not always. Like every nascent computer user sometimes even seasoned programmers arbitrarily distrust the machine.

Technofear.n - The result of seemingly random 
consequences caused by the actions of inept users 
leeding to a deep sense of confusion and distrust 
for technology. i.e. "programming the vcr"

You see, as a programmer, even more so than a user it is essential to be able to trust the tools that you use to produce the results that you expect. The programmer must have faith that the compiler tells the truth in all matters and all things.

For if the compiler lies, then the programmer is sure to spend many countless frustrating hours chasing bugs which don't exists. And eventually their confidence will be eroded to the point that they will also waste countless hours swearing at the compiler for producing an error, which in fact is genuine.

Unfortunately its a bit of a boy who cried wolf scenario, and the horrible truth and shame about the software industry, is that even today, all compilers lie.

Anyone who has ever misplaced a curly brace or two and received a cascade of endless random errors from their compiler knows this shameful fact of life.

So then, it is left to the programmer to develop their own intuitive understanding of the particular tools and compilers that they use, to the point that they know when an error is and error and when the machine just needs a good kick. This truly is the art of programming, and perhaps more than you might think it can separate the good programmers from the great programmers, and at the very least, the frustrated from the productive.

Ive just fixed a rather good example of such an error. And fortunately for me, i chose wisely in trusting the compiler in what seemed like a perfect opportunity not too. You see, my program was operating correctly in debug, but failing in release.

An obvious problem you may suggest, but not quite. You see, if i slowed the program down in release, it worked correctly. Ahhh! i hear you say, "clearly youve got a race condition between one or more threads". But alas, there is only a single thread and the timing is very subtle.

It sure did look like one of those occasions where one may be tempted to start looking under the rug for a wolf. But i held fast and debugged the code into the long hours of the night. And after much toiling, and tracing, and printing as there are only limited ways one can effectively debug release code, i started to narrow the trail.

After two days of debugging i found the problem.

It was caused by two objects being compared by memory addresses. In the world of debug code, memory addresses are consecutive manufactured things, contrived to make the task of debugging easier for the programmer. But in release code, memory addresses are random highly variable things. So in debug, object A was less than object B, but in release where the memory was different, object B was less than object A.

At its root was an innocuous problem, but it was burried deep in thousands of lines of code. Knowing when to trust and when to distrust your tools is critical, becuase sometimes...

The compiler is actually right.