Dangerous Cross-Roads

{$IFDEF Danger}...

Nobody can harm me, except myself.

St. John Chrysostom, speaking about his executioners

While preparing the FileSuite for release (already a beta is available for download) we will dig(g) once again in the dark areas of Delphi’s source code.

While in one of ours last posts we spoke about an opinion which now and then is a hot theme in Delphi community (the legendary var block) – and enough programmers expressed their concerns about the safety issues tied to this – today we’ll speak about something opposite…

While we’re concerned about making Pascal more flexible, we are quite happy with the overflow of “flexibility” given by the Pascal’s Conditional Compilation.

In the old (and golden) ages, the Conditional Compilation directives (the well known IFDefs) were rather a rare thing and just a basic support for them was enough. Now when the component developers (and not only) have to maintain some Delphi versions, now when the shareware authors have to support some versions of their program (I mean “Demo”, “Lite”, “Pro” etc.), now when the cross-platform and the 64bit compilation is coming near us, our environment lacks of appropriate support to assist the developer to achieve the promised RAD. Because we want Rapid Application Development, no?

Yes, a good start was made with Building Configurations but that thing helps the developer only in certain areas of its development process.

Enough with words, let’s have a look at a few examples, all taken from Delphi’s official RTL. First the nice ones.

Because there’s a loose check in what is entered (or not) in the $IFDEF directives we can have somewhat funny things like:

…IFDEF Linux in Windows Unit which has (incidentally) a copyright info from Microsoft: The enemy is inside.

or …gee… the Pascal isn’t pure yet:… (gem from System Unit)

But the lack of proper checks can unlock the most dangerous enemy of a programmer: himself.
That’s why it can appear sometimes much more dangerous things which can badly affect the code execution and also, very hard to debug, like this one found in the Delphi 2010’s System unit. As you see, it is missing just a character. One character. An underscore.

It is the single occurrence of this mistake, according to FileSuite. But it is enough.
Older versions of Delphi aren’t affected, though.

I think that definitely it should be imposed a stricter control of IfDefs. For example, in this case, to check if an EndIf exists without its corresponding opening IfDef/IfNDef counterpart. Also a code folding engine acting over these IfDefs would be a very welcomed addition – and if we’ll have the possibility to collapse / expand all the $IfDef Windoze at once would be really great. Of course the same stands for $IfDef Linux 🙂

Your opinion?