Possible syntax highlighting bug lazarus / 9-Editor ---------------------------------------------------------------------- 440bx · 2024-07-19 02:23 Lazarus v3.4 (latest release) 64 bit on Win7 SP1 Consider the following simple program: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$APPTYPE CONSOLE} program _SyntaxHighlighting; uses  Windows  ; var  Offset : DWORD; begin  Offset := ptruint(                    @TIMAGE_LOAD_CONFIG_DIRECTORY32(nil^).SeHandlerTable                   );    readln;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 · 2024-07-19 08:49 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i type I = integer; PI = ^I; // a pointer type// ORconst Tab = ^I; // a char constant ---------------------------------------------------------------------- Martin_fr · 2024-07-19 08:58 Ok, I thought it would be A-Z, but this compiles: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i writeln( ^) ); ---------------------------------------------------------------------- Martin_fr · 2024-07-19 09:15 fixed ---------------------------------------------------------------------- 440bx · 2024-07-19 12:16 Hello Martin, Quote from: Martin_fr on July 19, 2024, 11:15:20 amfixed That was quick. Should I still report it as a bug ? or forget it since it is already fixed ? Quote from: Martin_fr on July 19, 2024, 10:58:13 amOk, I thought it would be A-Z, but this compiles: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i 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 · 2024-07-19 13:56 Quote from: 440bx on July 19, 2024, 02:16:34 pmQuote from: Martin_fr on July 19, 2024, 10:58:13 amCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i 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 · 2024-07-19 14:10 Quote from: Martin_fr on July 19, 2024, 03:56:51 pmTrip 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: QuoteTURBO 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 · 2024-07-19 14:33 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 · 2024-07-19 14:42 Quote from: 440bx on July 19, 2024, 04:33:51 pmI 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 · 2024-07-19 14:47 Quote from: TRon on July 19, 2024, 04:42:00 pmIn 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 · 2024-07-22 21:19 Quote from: 440bx on July 19, 2024, 04:47:01 pmI 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Writeln(Ord(^A), ' ', Ord(^)), ' ', Ord(^()); The returned value is simply an addition/substraction by 64: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i                      if c<#64 then                         cstringpattern[len]:=chr(ord(c)+64)                       else                       cstringpattern[len]:=chr(ord(c)-64); ---------------------------------------------------------------------- 440bx · 2024-07-22 21:39 @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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i ^%^$^! ^(:= 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 · 2024-07-22 22:43 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 QuoteCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i     ^%^$^! ^(:= 1 to 5 do begin end; { for i := 1 to 5 ... etc }translates to Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i '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 · 2024-07-25 20:18 Quote from: 440bx on July 22, 2024, 11:39:17 pmI 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 · 2024-07-25 21:43 As I said in the previous post, that Delphi does it doesn't make it right. ---------------------------------------------------------------------- PascalDragon · 2024-07-28 16:23 Quote from: 440bx on July 25, 2024, 11:43:05 pmAs I said in the previous post, that Delphi does it doesn't make it right. And as both MvC and I said/implied: it doesn't matter whether you consider it not right. ---------------------------------------------------------------------- 440bx · 2024-07-28 16:48 Quote from: PascalDragon on July 28, 2024, 06:23:45 pmAnd as both MvC and I said/implied: it doesn't matter whether you consider it not right. I agree that my opinion isn't particularly important but, in spite of that, I do believe that long standing and accepted standards should be adhered to. ---------------------------------------------------------------------- PascalDragon · 2024-07-31 20:47 Quote from: 440bx on July 28, 2024, 06:48:00 pmQuote from: PascalDragon on July 28, 2024, 06:23:45 pmAnd as both MvC and I said/implied: it doesn't matter whether you consider it not right. I agree that my opinion isn't particularly important but, in spite of that, I do believe that long standing and accepted standards should be adhered to. The “long standing and accepted standard” in this case is TP (and Delphi), nothing else, because this has been implemented for compatibility with TP (and Delphi). ---------------------------------------------------------------------- 440bx · 2024-07-31 22:10 Quote from: PascalDragon on July 31, 2024, 10:47:40 pmThe “long standing and accepted standard” in this case is TP (and Delphi), nothing else, because this has been implemented for compatibility with TP (and Delphi). I should have known it's much more important to duplicate the bugs in TP and/or Delphi than to follow the American Standard Code for Information Interchange.  My mistake.