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?

9 thoughts on “Dangerous Cross-Roads

  1. >> … a copyright info from Microsoft: The enemy is inside.
    Agree: Somewhat disgusting:-), but only the other way around:-). The penguin digs its nose directly the heart … yes.

    I agree with you. Good old C never dies. Maybe an interesting idea for the IDE to show the code only for defines currently of interest (filter by $IFDEF MS_WINDOWS .. CRTL-X, CTRL+V;-)), maybe a technical workaround for something that should be avoided in general. It is hard to break with this tradition … on the other hand it gives one a clear picture of the differences on differnt OSes and for different situations …


  2. Interesting idea:
    > only show the code for defines currently of interest, filter by $IFDEF
    I would modify that to ‘Show the code that is Ifdef’ed out as comments
    using the current set of Defines.’

    You could clearly see that your defines/ifdefs were working.

  3. What danger? The code is correct, someone simply mistyped a comment in a harmless and obvious way. I vote no to requiring correct comments on $endif. I also vote no to hiding excluded code: I always want to see all of my code. I do, however, quite like the VS2008 method of graying excluded code (except when it gets the decision wrong).

  4. IFDEFs are a necessary evil. I wish the parser could read the DEFINEs and show them in code completion after an IFDEF – it would avoid some typing errors. Folding of ifdefsis something I’ve been asking for years.
    But I am very worried Delphic code is not reviewed properly…

  5. I have no idea what you’re getting at with this post.

    1. The copyright notice in the header of the Windows unit attributes the copyright of the LISTED C HEADER FILES and does not related to the Windows.pas unit itself.

    2. PURE_PASCAL_not_fixed_yet… right, so $DEFINEing PURE_PASCAL won’t start compiling code that isn’t fixed and ready for inclusion under PURE_PASCAL yet.

    3. Anything/everything following the $ENDIF is just a comment.

    None of these cases is any sort of issue worth commenting on, apart perhaps from the fact that the presence of PURE_PASCAL_not_fixed_yet is perhaps slightly embarrassing for the authors. There’s no danger to any code though.

    • The 3. is/was the issue for me. It is misleading. (1 and 2 was just for fun). One can write:

      {$ifdef a}
      {$ifdef b}
      {$endif a} //…or perhaps even forget it
      {$endif b} //…and the one who writes it to mean it

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s