Possible syntax highlighting bug

[440bx]

Lazarus v3.4 (latest release) 64 bit on Win7 SP1

Consider the following simple program:

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

1. {$APPTYPE CONSOLE}
2.  
3. program _SyntaxHighlighting;
4.  
5. uses
6.   Windows
7.   ;
8.  
9. var
10.   Offset : DWORD;
11.  
12. begin
13.   Offset := ptruint(
14.                     @TIMAGE_LOAD_CONFIG_DIRECTORY32(nil^).SeHandlerTable
15.                    );
16.  
17.  
18.   readln;
19. end.          

Refer to the attachment to see the color mismatch.

Notice the color of the typecast's close parenthesis does not match the color of the open parenthesis.  Normally all the parentheses are the same color.

Comments welcome.

[Martin_fr]

I like your wording "possible..." => leaves me the option to declare it a feature and walk away.

It looks like it thinks it is a string. The following prints a tab-char ("i" is the 9th char)

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

1. writeln('a'^i'b');

But why it does that with a closing bracket.... That shouldn't happen.

There are known cases where the HL currently can not distinguish between (nested types/const in structures...)

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

1. type I = integer; PI = ^I; // a pointer type
2. // OR
3. const Tab = ^I; // a char constant

[Martin_fr]

Ok, I thought it would be A-Z, but this compiles:

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

1. writeln( ^) );

[Martin_fr]

fixed

[440bx]

Hello Martin,

fixed

That was quick. Should I still report it as a bug ? or forget it since it is already fixed ?

Ok, I thought it would be A-Z, but this compiles:

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

1. writeln( ^) );

To my surprise it does compile and outputs "i".  Isn't that a compiler bug ?  "^)" doesn't look like a valid writeln argument... am I missing something ?

[Martin_fr]

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

1. writeln( ^) );

To my surprise it does compile and outputs "i".  Isn't that a compiler bug ?  "^)" doesn't look like a valid writeln argument... am I missing something ?

Trip down memory lane tells me I have seen it documented. But I couldn't find it now.

It is basically a syntax for Control characters. Such as the commonly seen ^C for Ctrl-C which produces the old ASCII #03  (C being the 3rd char), if you prevent the signal.

I don't know about it taking "char"s outside the a..z / A..Z range. No idea if that is a feature. Well, there is the fact that ctrl chars go from #01 to #31 => and a..z goes from 1 to 26.

[TRon]

Trip down memory lane tells me I have seen it documented. But I couldn't find it now.

Me neither in modern documentation (I am sure it is there but today is bleh)

Turbo pascal manual:

TURBO Pascal also allows control characters to be embedded in strings. Two
notations for control characters are supported: 1) The # symbol followed by
an integer constant in the range 0 .. 255 denotes a character of the corre-
sponding ASCII value, and 2) the ^ symbol followed by a character, denotes
the corresponding control character.

Sequences of control characters may be concatenated into strings by writing
them without separators between the individual characters::

[440bx]

I know/remember that the "^" followed by a character is interpreted as a control character identifier _but_ there is no "^)".  IOW, there is no control character (or plain character) identified by "^)".

Attached to this post is a snapshot that shows the known/accepted control characters and "^(" is not in the list.

I believe that FPC's acceptance of "^(" is a bug.  whatever "^(" may be, it certainly isn't the character "i" (which is what it outputs.)  I believe it should issue an error upon encountering an invalid character after the "^".

[TRon]

I know/remember that the "^" followed by a character is interpreted as a control character identifier _but_ there is no "^)".  IOW, there is no control character (or plain character) identified by "^)".

Ah ok.

In that case I misunderstood your question. Sorry for that because afaik you are right.

Control characters live in the 0..31 range (except of 32 and 127) and the c1 control characters are in the range 128..159.

[440bx]

In that case I misunderstood your question. Sorry for that because afaik you are right.

No problem. 

I use that little table in the snapshot somewhat often (it's part of the editor I use), that's why the "^(" immediately raised a red flag in my mind.  I knew there was no such thing as a "^(" control/"or otherwise" character.

Hopefully an FPC developer will see this thread/posts and emit an opinion.

[PascalDragon]

I use that little table in the snapshot somewhat often (it's part of the editor I use), that's why the "^(" immediately raised a red flag in my mind.  I knew there was no such thing as a "^(" control/"or otherwise" character.

Hopefully an FPC developer will see this thread/posts and emit an opinion.

Delphi also compiles code like this:

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

1. Writeln(Ord(^A), ' ', Ord(^)), ' ', Ord(^());

The returned value is simply an addition/substraction by 64:

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

1.                        if c<#64 then
2.                          cstringpattern[len]:=chr(ord(c)+64)
3.                        else
4.                          cstringpattern[len]:=chr(ord(c)-64);

[440bx]

@PascalDragon,

I don't know if you saw the bug report I created about these invalid control characters, my points are:

1. that Delphi accepts it does not make it right.
2. the ASCII standard defines the set of valid control characters and ^( , ^) are not in the set, thus they are invalid.

Lastly, presuming the character "f" is ^%, the character "o" is ^$ and "r" is ^1 then whoever wants to argue that those control sequences are valid has to explain why neither FPC nor Delphi accepts:

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

1. ^%^$^! ^(:= 1 to 5 do begin end; { for i := 1 to 5 ... etc }

For some "odd" reason the compiler's scanner doesn't accept these "valid" control characters but has no problems accepting those defined by the standard. (t accepts them in a writeln statement.)

PS: I didn't, nor will I, take the time to figure out what invalid control characters represent the string "for" (not worth the time.)

[Martin_fr]

The control chars are strings (or a char in quotes). Much the same as #65 is 'A' it is not just A.

So your example

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

1.     ^%^$^! ^(:= 1 to 5 do begin end; { for i := 1 to 5 ... etc }

translates to

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

1. 'for' 'i':= 1 to 5 do begin end;

That is in no way a comment on the remainder of the statement. I.e. should or shouldn't there be custom sequences.

[PascalDragon]

I don't know if you saw the bug report I created about these invalid control characters, my points are:

1. that Delphi accepts it does not make it right.
2. the ASCII standard defines the set of valid control characters and ^( , ^) are not in the set, thus they are invalid.

No, I didn't saw the bug report (till now), but as MvC said, it's not a bug that you can use such sequences. And as he also wrote, TP and Delphi support it, thus FPC must support it at least in modes TP and Delphi as well and thus there isn't really a good argument to forbid it in the other modes either. Not to mention that nowadays it's also necessary for backwards compatibility.

[440bx]

As I said in the previous post, that Delphi does it doesn't make it right.