unexpected behavior in FPC v3.2.2

[440bx]

Hello,

Consider the following program:

Code: Pascal  [Select][+][-]

1.  
2. {$define (NoClosingParenthesis}   { no complaint about missing parenthesis    }
3. {$define NoOpeningParenthesis)}   { no complaint about missing parenthesis    }
4.  
5.  
6. program _DirectivesParentheses;
7.  
8. begin
9. end.                  

Note that the compiler directives have mismatched parentheses, yet the compiler compiles that code without complaints.

Comments welcome.

[dbannon]

Its one or the other of -

• You have discovered a new compiler directive.
• The compiler does not check for matching Parenthesis inside a comment.

I think I prefer the latter.  A {$define } is a comment when you think about it, a comment left for the compiler rather than a human reader but still a comment.

Davo

[MarkMLl]

Its one or the other of -

• You have discovered a new compiler directive.
• The compiler does not check for matching Parenthesis inside a comment.

I think I prefer the latter.  A {$define } is a comment when you think about it, a comment left for the compiler rather than a human reader but still a comment.

Davo

What is the behaviour of the -d option on the commandline (with appropriate shell quoting/escaping)?

What is the behaviour of {$ifdef with those mismatched parentheses?

Can't check myself, out in a few mins.

MarkMLl

[440bx]

I think I prefer the latter.  A {$define } is a comment when you think about it, a comment left for the compiler rather than a human reader but still a comment.

It's a comment but one that must comply with some rules.  For instance:

Code: Pascal  [Select][+][-]

1. {$ifdef (SomeName}  // note the missing closing parenthesis

does NOT compile because the compiler insists on having a closing parenthesis in that "comment".

It was a reasonable thought but, directives are comments that are held to some rules they must follow.  Parentheses must be matched because they cannot be part of the identifier, therefore a lone parenthesis is an extraneous character.

[marcov]

IIRC there is a "feature" inherited from turbo pascal that trailing tokens of a $define are ignored. That explains the second one.

[dbannon]

Yes Marcov, the trailing Parentheses seems to be ignored, $ifdef finds the identifier both with and without the Parentheses. But the leading Parentheses is a problem.

Code: Pascal  [Select][+][-]

1. {$define (NoNothing}  
2. {$define NoSomething)}  
3.  
4. program _DirectivesParentheses;
5.  
6. begin
7. //      {$ifdef (NoNothing}             // This will not compile
8. //      writeln('(NoNothing');
9. //      {$endif}
10.         {$ifdef NoNothing}             
11.         writeln('NoNothing');    // This is NOT printed
12.         {$endif}
13.         {$ifdef NoSomething)}
14.         writeln('NoSomething)');   // This IS printed
15.         {$endif}
16.         {$ifdef NoSomething}
17.         writeln('NoSomething');   // This IS printed
18.         {$endif}
19. end.  
20.  

   

You could argue that the way it is here could lead to one of those bugs where we sit and stare at the computer screen, getting angrier by the minute until we spot that leading Parentheses. But I can think of a other things I'd like to see fixed first !

Davo

[Bart]

Delphi 7 does not allow the first one, but allows the second one.

Bart