FPC 3.2.0 Released ! lazarus / 60-Free Pascal ---------------------------------------------------------------------- marcov · 2020-06-20 10:09 Hello, Finally, the Free Pascal 3.2.0 release is available from our servers and from sourceforge. Changes that may break backwards compatibility will be documented at: http://wiki.freepascal.org/User_Changes_3.2.0. For an overview of what is new see https://wiki.freepascal.org/FPC_New_Features_3.2 The website has been update for the major targets and work is still being done for the rest. All downloads are available at the main FTP server and sourceforge. https://sourceforge.net/projects/freepascal/files/ ftp://ftp.freepascal.org/pub/fpc/dist/3.2.0/ Enjoy! The Free Pascal Compiler Team ---------------------------------------------------------------------- bonmario · 2020-06-20 10:29 Wow !!!! Great job. Thanks !!! ---------------------------------------------------------------------- fred · 2020-06-20 11:03 Nice  Thanks all! ---------------------------------------------------------------------- JuhaManninen · 2020-06-20 11:36 Quote from: marcov on June 20, 2020, 12:09:32 pmFinally, the Free Pascal 3.2.0 release is available from our servers and from sourceforge. Thank you Marco and others! I believe my Manjaro Linux will be updated in a week or so. This is one reason why frequent releases are important. Even rolling distributions publish just official releases although they try to provide the latest versions quickly. Their strategy does not work if an SW project does not release. Other distributions would benefit from frequent releases, too. They just have a delay. From my POV there is even a more important reason for frequent releases. Lazarus development version (trunk) is supposed to compile and work with 2 latest FPC releases. The rule would be reasonable with a decent FPC release cycle but with the current situation it is not. Most people must build their compilers themselves by some means. Many recent commits have not worked with the latest release 3.0.4 any more. The second latest 3.0.2 has not even been tested for years. I sincerely ask FPC project to create a proper release schedule and to stick with it! 3.2 was branched almost 2 years ago. FPC trunk is much ahead of it already. A new main release should be branched soon (this year) and released next year. ---------------------------------------------------------------------- BSaidus · 2020-06-20 11:46 Thank you team for your hard work. Thanks. ---------------------------------------------------------------------- cappe · 2020-06-20 12:33 fantastic thanks ---------------------------------------------------------------------- nouzi · 2020-06-20 13:52 Thanks for all work ---------------------------------------------------------------------- jwdietrich · 2020-06-20 16:56 Congratulations and thanks for your continued efforts. ---------------------------------------------------------------------- 440bx · 2020-06-20 17:24 Thank you FPC team for all your hard work.   Well done!. ---------------------------------------------------------------------- Max V. Terentiev · 2020-06-20 17:54 Thank you very much for your fantastic work ! And please, please, please make better debugger with ability to inspect property values ! ---------------------------------------------------------------------- heejit · 2020-06-20 18:56 Thanks to whole FPC Team and all contributors. ---------------------------------------------------------------------- jujibo · 2020-06-20 19:32 Great! Thanks. ---------------------------------------------------------------------- avra · 2020-06-20 20:02 Party time !!! ---------------------------------------------------------------------- dbannon · 2020-06-20 23:47 Well done folks ! Thanks heaps. A question, are there any changes between RC1 and the release version ? Davo ---------------------------------------------------------------------- trev · 2020-06-21 00:19 Error in this blurb on sourceforge: "Xcode 10/11 compatibility (macOS 10.14 Mojave and later) FPC 3.2.0 is qualified for use with Mac OS X 10.4 till macOS 10.15. Xcode 10 installs some command line file in different locations compared to previous releases. If you already installed FPC under a previous Mac OS X/OS X/macOS version, you will have to reinstall FPC 3.2.0a under macOS 10.14 to get a configuration file that enables the compiler to find the necessary files). See also the section below on how to install the command line tools." There is no FPC 3.2.0a ---------------------------------------------------------------------- winni · 2020-06-21 00:59 Hi! Thanx boys (and girls - if there are) I can throw my  unit for dynArrays in the Orcus! All by default now! Yippie! Winni ---------------------------------------------------------------------- fpcoder · 2020-06-21 01:56 Thank you! ---------------------------------------------------------------------- process_1 · 2020-06-21 02:27 https://sourceforge.net/projects/freepascal/files/Linux/3.2.0/ I do not see .deb packages for 32/64. I'm certainly missing something... ---------------------------------------------------------------------- dbannon · 2020-06-21 04:38 Quote from: process_1 on June 21, 2020, 04:27:26 am I do not see .deb packages for 32/64. I'm certainly missing something... Use the tar file and install in your home directory. apt install binutils make gcc subversion vim libgtk2.0-dev  libx11-dev (and maybe libqt5pas-dev) Get the tar file, extract it to somewhere in your home dir, set a path to the bin parts, put src somewhere in parallel.  Don't try and install as root.  Will use a fpc.cfg as a hidden file in home dir, need to run fpcmkcfg to generate it. maybe, and this from (dodgy) memory, fpcmkcfg -d basepath=$HOME/FPC/3.2.0 > $HOME/.fpc.cfg (Come on folks, time we had a best practice doc for this ....) Davo ---------------------------------------------------------------------- dsiders · 2020-06-21 05:24 So where is the Win64 compiler? I see a cross compiler for Win32. ---------------------------------------------------------------------- marcov · 2020-06-21 10:08 Free Pascal doesn't provide a win64 compiler, only a win32->win64 crosscompiler. The reason for that is that the win64 (due to the pecularities of Microsoft floating point support) can't bootstrap other i386/x86_64 compilers. ---------------------------------------------------------------------- simone · 2020-06-21 10:32 Will the next version of Lazarus be shipped with FPC 3.2.0?  If yes, when? Thanks! ---------------------------------------------------------------------- marcov · 2020-06-21 11:03 Quote from: simone on June 21, 2020, 12:32:03 pmWill the next version of Lazarus be shipped with FPC 3.2.0?  If yes, when? Thanks! Usually lazarus switches FPC version only with major Lazarus (.x.y.0) releases.  So it probably depends if the current series still has life in it or not. ---------------------------------------------------------------------- mika · 2020-06-21 13:23 Quote from: simone on June 21, 2020, 12:32:03 pmWill the next version of Lazarus be shipped with FPC 3.2.0?  If yes, when? Thanks! yes Quote from: JuhaManninen on March 30, 2020, 04:13:04 pmThe energy now goes towards the next major version, Lazarus 2.2, which will be branched around the time FPC 3.2 gets released. Then there will be release candidates before the actual release. Release of Lazarus 2.0 took 5 month. So, rounding up to 6 month from now could be realistic time for Lazarus 2.2 release. It's a guess, I can be as well wrong on this. ---------------------------------------------------------------------- Mr.Madguy · 2020-06-21 16:55 My question stays the same for many years. Is it Delphi 2009 compatible? Or not? I really want to fully migrate to Lazarus, cuz I've got sick of that "out of memory" problems with large modules. ---------------------------------------------------------------------- ASBzone · 2020-06-21 17:27 Quote from: marcov on June 20, 2020, 12:09:32 pmHello, Finally, the Free Pascal 3.2.0 release is available from our servers and from sourceforge. ... Enjoy! The Free Pascal Compiler Team Thanks, and congrats team... ---------------------------------------------------------------------- marcov · 2020-06-21 18:16 Quote from: Mr.Madguy on June 21, 2020, 06:55:18 pmMy question stays the same for many years. Is it Delphi 2009 compatible? Or not? I really want to fully migrate to Lazarus, cuz I've got sick of that "out of memory" problems with large modules. Large modules or auto generated crazy sized procedures? ---------------------------------------------------------------------- alaa123456789 · 2020-06-21 18:26 hi , thanks for your efforts could you please explain how to update it , i have lazarus 2.0.8 64 bit with fpc 3.04 thanks alaa ---------------------------------------------------------------------- dsiders · 2020-06-21 18:27 Quote from: marcov on June 21, 2020, 12:08:02 pmFree Pascal doesn't provide a win64 compiler, only a win32->win64 crosscompiler. The reason for that is that the win64 (due to the pecularities of Microsoft floating point support) can't bootstrap other i386/x86_64 compilers. Okay. I was wanting to replace the 64-bit compiler that's provided in the Lazarus install (./fpc/3.0.4/bin/x86_64-win64/fpc.exe). Does that mean we have to wait for a new Lazarus release with the actual 64-bit compiler? ---------------------------------------------------------------------- lainz · 2020-06-21 19:13 Thanks. Now to be shipped with Lazarus and time to get rid of trunk and his problems  I agree on that the releases should be made earlier, but I'm not a compiler programmer so I have no idea about that and what kind of tests are they running and about the time it takes. ---------------------------------------------------------------------- Mr.Madguy · 2020-06-21 19:49 Quote from: marcov on June 21, 2020, 08:16:20 pmLarge modules or auto generated crazy sized procedures? Generics. Yeah, I already use separate DLL for them. Not only due to this problem, but because I like well-structured projects, where one module can be updated without updating whole project. And I can always split it into 2, 3, etc. if situation will become critical. But it's 2020. And it's just not good, that 4Mb binary size is still so critical for compiler. ---------------------------------------------------------------------- chenyuchih · 2020-06-21 23:28 Great! What a exciting news! That's exact what I'm waiting for. And thank you all the development team members for creating such a good compiler. Nice Job! ---------------------------------------------------------------------- Marc · 2020-06-22 07:19 Quote from: marcov on June 21, 2020, 01:03:49 pmQuote from: simone on June 21, 2020, 12:32:03 pmWill the next version of Lazarus be shipped with FPC 3.2.0?  If yes, when? Thanks! Usually lazarus switches FPC version only with major Lazarus (.x.y.0) releases.  So it probably depends if the current series still has life in it or not. Plans are to release Lazarus 2.0.10 with FPC 3.2.0 within a few weeks ---------------------------------------------------------------------- PascalDragon · 2020-06-22 07:50 Quote from: Mr.Madguy on June 21, 2020, 06:55:18 pmMy question stays the same for many years. Is it Delphi 2009 compatible? Or not? I really want to fully migrate to Lazarus, cuz I've got sick of that "out of memory" problems with large modules. It depends on what you define as "compatible". There were improvements here, but not everything Delphi 2009 introduced is available (e.g. extended RTTI, anonymous functions). ---------------------------------------------------------------------- simone · 2020-06-22 09:07 It seems to me that the new language features (for example those relating to dynamic arrays and generics) are not yet described in the language reference guide, although this is indicated as version 3.2.0. ---------------------------------------------------------------------- PascalDragon · 2020-06-22 10:10 Quote from: simone on June 22, 2020, 11:07:07 amIt seems to me that the new language features (for example those relating to dynamic arrays and generics) are not yet described in the language reference guide, although this is indicated as version 3.2.0. That indeed appears to be the case. Please report bugs for these. ---------------------------------------------------------------------- Mr.Madguy · 2020-06-22 10:18 Quote from: PascalDragon on June 22, 2020, 09:50:48 amIt depends on what you define as "compatible". There were improvements here, but not everything Delphi 2009 introduced is available (e.g. extended RTTI, anonymous functions). Closures are required for my project. I can't get rid of them. They're used as unit test callbacks with ability to pass arbitrary data to them via capturing. I mean Delphi 2009 compatible - any Delphi 2009 project can be compiled via FPC. May be with some minor tweaks. ---------------------------------------------------------------------- JernejL · 2020-06-22 12:22 Quote from: Mr.Madguy on June 22, 2020, 12:18:20 pmQuote from: PascalDragon on June 22, 2020, 09:50:48 amIt depends on what you define as "compatible". There were improvements here, but not everything Delphi 2009 introduced is available (e.g. extended RTTI, anonymous functions). Closures are required for my project. I can't get rid of them. They're used as unit test callbacks with ability to pass arbitrary data to them via capturing. I mean Delphi 2009 compatible - any Delphi 2009 project can be compiled via FPC. May be with some minor tweaks. They are working in that in bugtracker and mailing list: https://bugs.freepascal.org/view.php?id=24481 ---------------------------------------------------------------------- PascalDragon · 2020-06-22 12:34 Quote from: Mr.Madguy on June 22, 2020, 12:18:20 pmQuote from: PascalDragon on June 22, 2020, 09:50:48 amIt depends on what you define as "compatible". There were improvements here, but not everything Delphi 2009 introduced is available (e.g. extended RTTI, anonymous functions). Closures are required for my project. I can't get rid of them. They're used as unit test callbacks with ability to pass arbitrary data to them via capturing. I mean Delphi 2009 compatible - any Delphi 2009 project can be compiled via FPC. May be with some minor tweaks. Well, that will have to wait at least till 3.4 then. ---------------------------------------------------------------------- TRon · 2020-06-22 12:49 Quote from: PascalDragon on June 22, 2020, 12:10:47 pmQuote from: simone on June 22, 2020, 11:07:07 amIt seems to me that the new language features (for example those relating to dynamic arrays and generics) are not yet described in the language reference guide, although this is indicated as version 3.2.0. That indeed appears to be the case. Please report bugs for these. Uhm, does that also apply for the definition pictures used in the reference guide ? e,g, they currently do not take generics definition(s) into account. ---------------------------------------------------------------------- peardox · 2020-06-22 12:53 It don't work on Mac with Lazarus... ---------------------------------------------------------------------- process_1 · 2020-06-22 13:10 I have extracted FPC 3.2.0 from .TAR archive and installed on ubuntu, no problems However, I do not see SRC for 3.2.0 in .TAR, only  .RPM. This can be extracted anyway and used in Ubuntu, or better to download from SourceForge with SVN or GIT? ---------------------------------------------------------------------- TRon · 2020-06-22 13:51 Quote from: process_1 on June 22, 2020, 03:10:00 pmHowever, I do not see SRC for 3.2.0 in .TAR, only  .RPM. This can be extracted anyway and used in Ubuntu, or better to download from SourceForge with SVN or GIT? https://sourceforge.net/projects/freepascal/files/Source/3.2.0/ ---------------------------------------------------------------------- PascalDragon · 2020-06-22 13:54 Quote from: TRon on June 22, 2020, 02:49:55 pmQuote from: PascalDragon on June 22, 2020, 12:10:47 pmQuote from: simone on June 22, 2020, 11:07:07 amIt seems to me that the new language features (for example those relating to dynamic arrays and generics) are not yet described in the language reference guide, although this is indicated as version 3.2.0. That indeed appears to be the case. Please report bugs for these. Uhm, does that also apply for the definition pictures used in the reference guide ? e,g, they currently do not take generics definition(s) into account. They are documented in a completely separate topic currently. Though the graph is rather broken there right now... ---------------------------------------------------------------------- TRon · 2020-06-22 14:03 @PascalDragon Thanks. I couldn't come up with the correct name in my previous post, syntax diagram it is. Although rather broken, i do get the picture there  edit: thank you team, for the new release and congratulations on another milestone reached! ---------------------------------------------------------------------- antispam88 · 2020-06-23 02:45 Hi, well done. But I have an issue with my class/interface hierarchic which is working with 2.0.8 / 3.0.4. But with 2.0.8 / 3.2.0 I'm getting the error 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 unit1.pas(54,13) Error: No matching implementation for interface method "SetLevel(const AnsiString);" found Is my hierachic correct? Best regards, antispam88 ---------------------------------------------------------------------- eljo · 2020-06-23 02:54 Quote from: antispam88 on June 23, 2020, 04:45:29 amHi, well done. But I have an issue with my class/interface hierarchic which is working with 2.0.8 / 3.0.4. But with 2.0.8 / 3.2.0 I'm getting the error 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 unit1.pas(54,13) Error: No matching implementation for interface method "SetLevel(const AnsiString);" found Is my hierachic correct? Best regards, antispam88 please start a new thread for questions outside the fpc or rtl. In any case, you are implementing an interface that has a method named Setlevel the declaration of that method is different in the interface and your class that implements it.  For more info please share the details of that method or even better the interface and its implementation ---------------------------------------------------------------------- antispam88 · 2020-06-23 03:06 Quote from: antispam88 on June 23, 2020, 04:45:29 amHi, well done. But I have an issue with my class/interface hierarchic which is working with 2.0.8 / 3.0.4. But with 2.0.8 / 3.2.0 I'm getting the error 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 unit1.pas(54,13) Error: No matching implementation for interface method "SetLevel(const AnsiString);" found Is my hierachic correct? Best regards, antispam88 Thank you for your reply. Is project1.zip not attached? 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   { IInterface1 }   IInterface1 = interface(IUnknown)    ['{C39204A5-CD80-44F5-95CB-8FD711783B98}']    procedure SetLevel(const alevel1, alevel2: integer);    procedure SetLevel(const alevel12: string); overload;  end;   { TClass1 }   TClass1 = class(TInterfacedObject, IInterface1)  protected    level1: integer;  level2: integer;  public    procedure SetLevel(const alevel1, alevel2: integer); virtual;    procedure SetLevel(const alevel12: string); overload;  end;   { IInterface2 }   IInterface2 = interface(IInterface1)    ['{1C1F8266-8923-452A-B3F4-C8C28381915A}']  end;   { TClass2 }   TClass2 = class(TClass1, IInterface2)  protected    param1: integer;  public    procedure SetParam1(const aparam1: integer);  end;   { IInterface3 }   IInterface3 = interface(IInterface2)    ['{4B8F5FAC-3F5C-453F-A604-500A20EAA95A}']  end;   { TClass3 }   TClass3 = class(TClass2, IInterface3)  public    procedure SetLevel(const alevel1, alevel2: integer); override;  end; implementation { TClass1 } procedure TClass1.SetLevel(const alevel1, alevel2: integer);begin  level1 := alevel1;  level2 := alevel2;end; procedure TClass1.SetLevel(const alevel12: string);begin  level1 := StrToInt(alevel12);  level2 := StrToInt(alevel12) div 1000;end; { TClass2 } procedure TClass2.SetParam1(const aparam1: integer);begin  param1 := aparam1;end; { TClass3 } procedure TClass3.SetLevel(const alevel1, alevel2: integer);begin  level1 := alevel1 * 2;  level2 := alevel2 * 3;end;  And is my problem not regarding to fpc? The only change between both scenarios is the fpc version (3.0.4 -> 3.2.0). Best regards, antispam ---------------------------------------------------------------------- ASerge · 2020-06-23 03:49 Quote from: antispam88 on June 23, 2020, 05:06:51 amBut with 2.0.8 / 3.2.0 I'm getting the error 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 unit1.pas(54,13) Error: No matching implementation for interface method "SetLevel(const AnsiString);" foundIs my hierachic correct? Carefully read Methods_implementing_interface_methods_and_overloads from User_Changes_3.2.0 and add an overload directive. ---------------------------------------------------------------------- antispam88 · 2020-06-23 05:42 Quote from: ASerge on June 23, 2020, 05:49:09 amQuote from: antispam88 on June 23, 2020, 05:06:51 amBut with 2.0.8 / 3.2.0 I'm getting the error 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 unit1.pas(54,13) Error: No matching implementation for interface method "SetLevel(const AnsiString);" foundIs my hierachic correct? Carefully read Methods_implementing_interface_methods_and_overloads from User_Changes_3.2.0 and add an overload directive. Thank you for your answer. This was the solution. Best regards, antispam ---------------------------------------------------------------------- eny · 2020-06-23 16:43 Another milestone. Many thx for all the hard work! ---------------------------------------------------------------------- flowCRANE · 2020-06-24 10:12 Nice to see the new compiler — good job, guys. Quote from: PascalDragon on June 22, 2020, 09:50:48 amIt depends on what you define as "compatible". There were improvements here, but not everything Delphi 2009 introduced is available (e.g. extended RTTI, anonymous functions). Any plans for the future related to the implementation of anonymous methods? ---------------------------------------------------------------------- PascalDragon · 2020-06-24 11:41 Quote from: furious programming on June 24, 2020, 12:12:20 pmAny plans for the future related to the implementation of anonymous methods? Work in progress. ---------------------------------------------------------------------- DonAlfredo · 2020-06-28 18:46 Fpcupdeluxe uses the required bootstrap versions that are available in the FPC Makefile. Now it seems that FPC 3.2.0 also defines itself (3.2.0) as bootstrapper. Is this a new policy ? ---------------------------------------------------------------------- marcov · 2020-06-28 20:29 Quote from: DonAlfredo on June 28, 2020, 08:46:44 pmFpcupdeluxe uses the required bootstrap versions that are available in the FPC Makefile. Now it seems that FPC 3.2.0 also defines itself (3.2.0) as bootstrapper. Is this a new policy ? Afaik both the release_3_2_0 and fixes_3_2 and trunk branches accept 3.0.4 and 3.2.0 as bootstrap. But for fixes_3_2 and trunk, formally 3.2.0 is preferred.release_3_2_0 should be able to auto-bootstrap (e.g. for cross compilers of new targets), and of course 3.0.4 to build a chain[/l] So I don't see a new policy or problem to be honest. The policy is as always, use the released version logically before it (so 3.0.4 for 3.2.0 and 3.2.0 for 3.2.1 and trunk) ---------------------------------------------------------------------- glorfin · 2020-07-03 20:48 Thanks and Congratulations! ---------------------------------------------------------------------- Dmitry24 · 2020-07-09 15:48 I can see a bug found in 3.2.0rc1 reported "resolved" months ago which fix is not merged in the final version 3.2.0: https://bugs.freepascal.org/view.php?id=36863 How can I find out which bugs are fixed in the 3.2.0 and which are not? In which FPC version will these bug fixes be merged? ---------------------------------------------------------------------- marcov · 2020-07-09 16:14 Quote from: Dmitry24 on July 09, 2020, 05:48:21 pmHow can I find out which bugs are fixed in the 3.2.0 and which are not? The only hard way is getting the list of revisions eligible for merging of the 3.2.0 branch. QuoteIn which FPC version will these bug fixes be merged? In the next major version, unless a maintainer merges it, or has somebody else merge it. ---------------------------------------------------------------------- PascalDragon · 2020-07-10 07:16 Quote from: Dmitry24 on July 09, 2020, 05:48:21 pmI can see a bug found in 3.2.0rc1 reported "resolved" months ago which fix is not merged in the final version 3.2.0: https://bugs.freepascal.org/view.php?id=36863 Something being fixed based on a bug report for an RC does not automatically mean that it will be part of the final release. ---------------------------------------------------------------------- Dmitry24 · 2020-07-13 05:48 Quote from: PascalDragon on July 10, 2020, 09:16:12 amQuote from: Dmitry24 on July 09, 2020, 05:48:21 pmI can see a bug found in 3.2.0rc1 reported "resolved" months ago which fix is not merged in the final version 3.2.0: https://bugs.freepascal.org/view.php?id=36863 Something being fixed based on a bug report for an RC does not automatically mean that it will be part of the final release. Waiting 3 years to get a release where debugging is not possible is actually frustrating. Another big problem is that the next Lazarus version will be based on that FPC release. ---------------------------------------------------------------------- Zoran · 2020-07-13 06:33 Quote from: PascalDragon on July 10, 2020, 09:16:12 amSomething being fixed based on a bug report for an RC does not automatically mean that it will be part of the final release. If it is a regression from previous release (as said in bug report), would you merge to fixes branch? ---------------------------------------------------------------------- PascalDragon · 2020-07-13 07:25 Quote from: Zoran on July 13, 2020, 08:33:50 amQuote from: PascalDragon on July 10, 2020, 09:16:12 amSomething being fixed based on a bug report for an RC does not automatically mean that it will be part of the final release. If it is a regression from previous release (as said in bug report), would you merge to fixes branch? For compiler changes it's usually best if the one who did it (in this case Florian) does it or triggers Marco to do it as mainly the original developer knows the implications of the merge. Marco does not merge compiler changes by himself. ---------------------------------------------------------------------- mobydick426 · 2020-07-13 15:32 Hi, Thanks for the update ! Strangely, my antivirus tells me that fpc.exe contains a virus. This is the only one file that is rejected by antivirus (GData). As one of GData engine uses BitDefender database, is there anyone who have this error too ? What can be done ? Thanks ! ---------------------------------------------------------------------- lucamar · 2020-07-13 16:24 Quote from: mobydick426 on July 13, 2020, 05:32:14 pmWhat can be done ? First make sure (by checking the checksum) that your download is correct and, if so, tell your antivirus to ignore this "detection". Antiviruses frequently tag assemblers, compilers, debuggers, etc. for, among others, the simple reason that they are used to "modify" executables, which is also a virus "signature". If you're sure you have a clean copy you can ignore it and tell the antivirus to ignore it too. They already ignore the most common tools (say, GCC, Visual C, etc.) but the less common ones (like FPC) still give problems. ---------------------------------------------------------------------- Jackofall1 · 2020-07-20 21:40 Hi I just downloaded, 7/20/2020, the Free Pascal 3.2.0 from the Source Forge mirror site, and during the install Bitdefender stopped it and identified a trojan "Gen:Trojan.Heur.TP.gyW@bagP5ah." .  I do not know if this is a false positive or a real threat.  But I thought I would share the information. Thank you ---------------------------------------------------------------------- winni · 2020-07-20 21:56 Hi! The false positive alarm of Bitdefender increases in the last year. The last false positive alarm was about YajHFC (Yet another Java HylaFAX client) which runs on our Windows clients since 7 years. Unchanged. There were some more issue with false positive of Bitdefender. Hard times for the AV companies. Winni ---------------------------------------------------------------------- Jackofall1 · 2020-07-20 22:08 Hi Winni How does a person find out what the checksum of the original file is?  And what is an easy way for me to check the checksum of the downloaded file?  I am working on a Windows 10 o/s 64 bit. Thank you Jack ---------------------------------------------------------------------- Cyrax · 2020-07-20 23:55 Please report it to BitDefender. They have necessary means to identify if it is a false positive or not. ---------------------------------------------------------------------- ASBzone · 2020-07-21 03:38 Quote from: winni on July 20, 2020, 11:56:22 pmHi! The false positive alarm of Bitdefender increases in the last year. The last false positive alarm was about YajHFC (Yet another Java HylaFAX client) which runs on our Windows clients since 7 years. Unchanged. There were some more issue with false positive of Bitdefender. Hard times for the AV companies. Winni Most of them fail in the heuristics analysis functionality. ---------------------------------------------------------------------- Seenkao · 2020-11-27 06:15 День добрый! Я зачастую использую Byte, Word, LongWord в качестве флагов. Прилагаю снимок экрана. И я хотел бы узнать, тот код, что выделен, в таком варианте и попадает в программу? Если да, то по какой причине, проверка осуществляется в процессе исполнения программы? Почему эта проверка не происходит на этапе компоновки, когда ещё программа не скомпилирована. Я специально проверил, да, программа вылетает по ошибке, сообщая, что было переполнение. Но не было ни какого предупреждения, что число взято больше чем возможно взять. В данном случае, я думаю, изначально должно идти предупреждение и, если программист (человек создающий программу) не хочет обращать внимания на то что ему сообщил компилятор, то просто "обрезать" ему это число. Данная проверка, ни как не поможет ни разработке программы, ни её работе, ни поиску произошедших ошибок. google translate: Good afternoon! I often use Byte, Word, LongWord as flags. Attached is a screenshot. And I would like to know the code that is highlighted, in this variant and gets into the program? If so, for what reason, the check is carried out during the execution of the program? Why does this check not occur at the link stage, when the program has not yet been compiled. I specifically checked, yes, the program crashes by mistake, reporting that there was an overflow. But there was no warning that the number was taken more than it was possible to take. In this case, I think, initially there should be a warning, and if the programmer (the person creating the program) does not want to pay attention to what the compiler told him, then simply "cut off" this number for him. This check will neither help the development of the program, nor its work, nor the search for errors that have occurred. ---------------------------------------------------------------------- ccrause · 2020-11-27 09:54 Quote from: Seenkao on November 27, 2020, 07:15:23 am Good afternoon! I often use Byte, Word, LongWord as flags. Attached is a screenshot. And I would like to know the code that is highlighted, in this variant and gets into the program? If so, for what reason, the check is carried out during the execution of the program? Why does this check not occur at the link stage, when the program has not yet been compiled. I specifically checked, yes, the program crashes by mistake, reporting that there was an overflow. But there was no warning that the number was taken more than it was possible to take. In this case, I think, initially there should be a warning, and if the programmer (the person creating the program) does not want to pay attention to what the compiler told him, then simply "cut off" this number for him. This check will neither help the development of the program, nor its work, nor the search for errors that have occurred. This is a technical question, you may get more knowledgeable responses when posting this in the General or FPC development boards. I'm no expert, my guess is as follows: the compiler converts values to native CPU size before operating on the values possibly to prevent partial register stalls.  The CPU then cannot signal range overflow of small types (byte and word size) and the generated code needs to inspect the result to determine if it overflows the range of the destination type.  While this does not in principle  prevent compile time range checking, I suspect the node types have been changed by the time the compiler gets to the inner instructions (or and := in your code) hence compile time range checking will have to span across more than one conversion node, making it complicated to implement. ---------------------------------------------------------------------- Seenkao · 2020-11-27 12:30 ccrause, thanks! Вы наверно не заметили, внутри выделенного завёрнут отладочный код. Который проверяем размерность, и если размер вне диапазона, то выдаёт ошибку и программа "вылетает" с ошибкой. Этого кода не должно быть там в принципе! Он увеличивает размеры программы, ни как не влияет на работоспособность конечной программы (когда отключена отладка) и, добавляет ошибки в код, когда отладка включена. Если мы сделали программу и случайно напечатали число больше чем возможно, то при обычной компиляции число просто "отрежется" (без предупреждений!!!) и будет нормально работать. А когда захотим отладить этот код, то при запуске, мы спокойно получим "Error 211" - потому что в код был добавлен отладочный код. А причину возникновения подобной ошибки, трудно найти. Ведь изначально программа работала нормально. google translate: You probably did not notice, debug code is wrapped inside the selection. It checks the dimension, and if the size is out of range, it generates an error and the program crashes with an error. This code should not be there in principle! It increases the size of the program, in any way does not affect the performance of the final program (when debugging is disabled) and, adds errors to the code when debugging is enabled. If we made a program and accidentally printed a number larger than possible, then during normal compilation the number will simply be "cut off" (no warnings !!!) and will work fine. And when we want to debug this code, then at startup, we will get "Error 211" - because the debug code was added to the code. And the reason for such an error is difficult to find. After all, initially the program worked fine. ---------------------------------------------------------------------- PascalDragon · 2020-11-27 14:36 Quote from: Seenkao on November 27, 2020, 01:30:48 pmYou probably did not notice, debug code is wrapped inside the selection. It checks the dimension, and if the size is out of range, it generates an error and the program crashes with an error. This code should not be there in principle! It increases the size of the program, in any way does not affect the performance of the final program (when debugging is disabled) and, adds errors to the code when debugging is enabled. As ccrause said, Pascal evaluates (in this case) Field or ACTIVE using the native width of the processor (in this case 64-bit) and then assigns this again to a 8-bit field. Thus it inserts a range check upon the assignment as long as range checks are enabled. Quote from: Seenkao on November 27, 2020, 01:30:48 pmIf we made a program and accidentally printed a number larger than possible, then during normal compilation the number will simply be "cut off" (no warnings !!!) and will work fine. And when we want to debug this code, then at startup, we will get "Error 211" - because the debug code was added to the code. And the reason for such an error is difficult to find. After all, initially the program worked fine. No, if compilation with range checks triggers an error then your program might appear to work fine if compiled without range checks, but it contained errors nevertheless. And these might show in even harder to debug circumstances. ---------------------------------------------------------------------- Seenkao · 2020-11-27 14:59 Quote from: PascalDragon on November 27, 2020, 03:36:10 pmAs ccrause said, Pascal evaluates (in this case) Field or ACTIVE using the native width of the processor (in this case 64-bit) and then assigns this again to a 8-bit field. Thus it inserts a range check upon the assignment as long as range checks are enabled. No, if compilation with range checks triggers an error then your program might appear to work fine if compiled without range checks, but it contained errors nevertheless. And these might show in even harder to debug circumstances. Я лишь оповестил. Вероятно, вы ещё не раз столкнётесь с этой проблемой. И чтоб от неё избавится, лучше данный код сделать на эмулируемом уровне, и,  было бы хорошо чтоб он вообще не включался в рабочий код. (многие даже не отключают отладку и не знают об этом). google translate: I only notified. You will probably encounter this problem more than once. And in order to get rid of it, it is better to make this code at the emulated level, and it would be good that it should not be included in the working code at all. (many don't even turn off debugging and don't know about it). ---------------------------------------------------------------------- PascalDragon · 2020-11-28 10:11 Quote from: Seenkao on November 27, 2020, 03:59:48 pmI only notified. You will probably encounter this problem more than once. And in order to get rid of it, it is better to make this code at the emulated level, and it would be good that it should not be included in the working code at all. (many don't even turn off debugging and don't know about it). As long as it doesn't show a bug nothing will be changed there, cause that is how it's designed to be. ---------------------------------------------------------------------- Seenkao · 2020-11-28 10:55 Я извиняюсь, но ваш ответ больше похож на: " Нам наплевать на данную ошибку". google translate: I'm sorry, but your answer is more like: "We don't give a damn about this error." ---------------------------------------------------------------------- Igor · 2020-11-28 12:11 Hi, When do you plan RC or final version for FPC 3.2.1? ---------------------------------------------------------------------- PascalDragon · 2020-11-28 14:49 Quote from: Seenkao on November 28, 2020, 11:55:11 amI'm sorry, but your answer is more like: "We don't give a damn about this error." You did not show that is indeed an error. You only showed some screenshot with some code snippet with no explanation how Field and ACTIVE are declared only stating that enabling range checking leads to problems for you. So unless you provide a self contained, compilable example that shows that something fails then there is no error to give a damn about. Quote from: Igor Kokarev on November 28, 2020, 01:11:28 pmWhen do you plan RC or final version for FPC 3.2.1? We are currently in the progress of merging fixes and improvements from trunk, so it will still take some time. Maybe before Christmas, but don't take that for granted. ---------------------------------------------------------------------- rvk · 2020-11-28 14:58 Quote from: Seenkao on November 27, 2020, 07:15:23 amIf so, for what reason, the check is carried out during the execution of the program? Why does this check not occur at the link stage, when the program has not yet been compiled.Range checks errors can't usually be checked during compilation/linking. Some will (i.e. accessing array[-1] of an array[0..100]) but with a variable there is no way to check during linking, only during execution of your program. That's why you should debug and test with range check on. After that, when you check your program is flawless ( ) you can disable range check (and other debugging options) for your release to client. ---------------------------------------------------------------------- Seenkao · 2020-11-28 15:35 Quote from: rvk on November 28, 2020, 03:58:36 pmRange checks errors can't usually be checked during compilation/linking. Some will (i.e. accessing array[-1] of an array[0..100]) but with a variable there is no way to check during linking, only during execution of your program. That's why you should debug and test with range check on. After that, when you check your program is flawless ( ) you can disable range check (and other debugging options) for your release to client. Флаги нельзя проверять по переменным! А если это будет сделано, то компилятор как раз выдаст ошибку, если переменные будут разной размерности. google translate: Flags cannot be checked against variables! And if this is done, then the compiler will just give an error if the variables are of different dimensions. PascalDragon, 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 ...const  EDIT_TRUE     = $FFFFFFFFF;         // <--- typo (I did it on purpose)...var  EditMode : LongWord;                   //  Byte or Word - ignored if not more LongWord...procedure ...    if not (EditMode and EDIT_TRUE) = 0 then    begin      EditMode := EditMode or EDIT_TRUE;                          // <-- work!!! always      EditMode := EditMode or $1 0000 0000;                      // <-- when debugging is enabled, the dimension                               // checking code is inserted next                              // and even if the program was working, it will not work when debugging                            // (overflow enabled)      newEdit[EditOne].Flags := newEdit[EditOne].Flags or ACTIVE;    end    else begin    ... OS - Linux CPU - x86_64 I hope I have detailed enough? P.S. in the structure the bytes will be checked for dimension. ---------------------------------------------------------------------- PascalDragon · 2020-11-28 16:31 Quote from: Seenkao on November 28, 2020, 04:35:36 pmI hope I have detailed enough? I still had to guess quite a bit. A simple program I can stuff into the compiler is quite essential! Nevertheless I came up with the following: 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 program trangeerr; {$mode delphi} const  EDIT_TRUE     = $FFFFFFFFF;         // <--- typo (I did it on purpose) var  EditMode : LongWord;                 //  Byte or Word - ignored if not more LongWord const  ACTIVE = 2; type  TEdit = record    Flags: LongWord;  end; procedure Test;const  EditOne = 1;var  newEdit: array[0..1] of TEdit;begin  //if not (EditMode and EDIT_TRUE) = 0 then  begin    EditMode := EditMode or EDIT_TRUE;                          // <-- work!!! always    EditMode := EditMode or $100000000;                      // <-- when debugging is enabled, the dimension                            // checking code is inserted next                            // and even if the program was working, it will not work when debugging                          // (overflow enabled)    newEdit[EditOne].Flags := newEdit[EditOne].Flags or ACTIVE;  end;end; begin  Test;end. When compiled without -Cr no error will happen, but if compiled with -Cr there'll be a runtime error at line 27 as it should be. It is right that the compiler currently does not complain at compile time, because it can't. Once the compiler does the EditMode or EDIT_TRUE operation (which will result in a value of native width, in the case of a 64-bit target indeed a 64-bit value) it no longer knows that a constant was involved and thus it can't generate an error at compile time when that value is assigned to EditMode. And EditMode or EDIT_TRUE is a valid expression even if EDIT_TRUE is larger than the size of EditMode. ---------------------------------------------------------------------- Seenkao · 2020-11-28 16:59 Quote from: Seenkao on November 28, 2020, 04:35:36 pmP.S. in the structure the bytes will be checked for dimension. Quote from: PascalDragon on November 28, 2020, 05:31:00 pmIt is right that the compiler currently does not complain at compile time, because it can't. Once the compiler does the EditMode or EDIT_TRUE operation (which will result in a value of native width, in the case of a 64-bit target indeed a 64-bit value) it no longer knows that a constant was involved and thus it can't generate an error at compile time when that value is assigned to EditMode. And EditMode or EDIT_TRUE is a valid expression even if EDIT_TRUE is larger than the size of EditMode. Понятно, байты проверяет и этого достаточно... Всего доброго! ---------------------------------------------------------------------- Igor · 2020-11-29 11:18 Quote from: PascalDragon on November 28, 2020, 03:49:21 pm Quote from: Igor Kokarev on November 28, 2020, 01:11:28 pmWhen do you plan RC or final version for FPC 3.2.1? We are currently in the progress of merging fixes and improvements from trunk, so it will still take some time. Maybe before Christmas, but don't take that for granted. Thanks! This release is very important, because it officially supports target aarch64-darwin I'm having problem with using compiled FPC 3.2.1 fixes. So I hope that a package will correctly install FPC 3.2.1 on my Intel Mac. ---------------------------------------------------------------------- mrblack · 2020-12-05 02:08 Hello folks! I'd like to use free pascal with visual studio code, and i'm wondering, how to set ptop formatter with it? I can't find an executable. Thanks for the help. Pascal rules! UPD apt show fp-utils-3.0.4