Recent

Author Topic: Possible syntax highlighting bug  (Read 2731 times)

440bx

  • Hero Member
  • *****
  • Posts: 4731
Possible syntax highlighting bug
« on: July 19, 2024, 04:23:49 am »

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.
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10551
  • Debugger - SynEdit - and more
    • wiki
Re: Possible syntax highlighting bug
« Reply #1 on: July 19, 2024, 10:49:53 am »
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

  • Administrator
  • Hero Member
  • *
  • Posts: 10551
  • Debugger - SynEdit - and more
    • wiki
Re: Possible syntax highlighting bug
« Reply #2 on: July 19, 2024, 10:58:13 am »
Ok, I thought it would be A-Z, but this compiles:
Code: Pascal  [Select][+][-]
  1. writeln( ^) );

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10551
  • Debugger - SynEdit - and more
    • wiki
Re: Possible syntax highlighting bug
« Reply #3 on: July 19, 2024, 11:15:20 am »
fixed

440bx

  • Hero Member
  • *****
  • Posts: 4731
Re: Possible syntax highlighting bug
« Reply #4 on: July 19, 2024, 02:16:34 pm »
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 ?
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10551
  • Debugger - SynEdit - and more
    • wiki
Re: Possible syntax highlighting bug
« Reply #5 on: July 19, 2024, 03:56:51 pm »
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

  • Hero Member
  • *****
  • Posts: 3623
Re: Possible syntax highlighting bug
« Reply #6 on: July 19, 2024, 04:10:19 pm »
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:
Quote
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::
This tagline is powered by AI (AI advertisement: Free Pascal the only programming language that matters)

440bx

  • Hero Member
  • *****
  • Posts: 4731
Re: Possible syntax highlighting bug
« Reply #7 on: July 19, 2024, 04:33:51 pm »
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 "^".
(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

TRon

  • Hero Member
  • *****
  • Posts: 3623
Re: Possible syntax highlighting bug
« Reply #8 on: July 19, 2024, 04:42:00 pm »
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.
This tagline is powered by AI (AI advertisement: Free Pascal the only programming language that matters)

440bx

  • Hero Member
  • *****
  • Posts: 4731
Re: Possible syntax highlighting bug
« Reply #9 on: July 19, 2024, 04:47:01 pm »
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.

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

PascalDragon

  • Hero Member
  • *****
  • Posts: 5755
  • Compiler Developer
Re: Possible syntax highlighting bug
« Reply #10 on: July 22, 2024, 11:19:43 pm »
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

  • Hero Member
  • *****
  • Posts: 4731
Re: Possible syntax highlighting bug
« Reply #11 on: July 22, 2024, 11:39:17 pm »
@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.)

(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10551
  • Debugger - SynEdit - and more
    • wiki
Re: Possible syntax highlighting bug
« Reply #12 on: July 23, 2024, 12:43:38 am »
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
Quote
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

  • Hero Member
  • *****
  • Posts: 5755
  • Compiler Developer
Re: Possible syntax highlighting bug
« Reply #13 on: July 25, 2024, 10:18:51 pm »
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

  • Hero Member
  • *****
  • Posts: 4731
Re: Possible syntax highlighting bug
« Reply #14 on: July 25, 2024, 11:43:05 pm »
As I said in the previous post, that Delphi does it doesn't make it right.


(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

 

TinyPortal © 2005-2018