Recent

Author Topic: FPC 3.2.0 Released !  (Read 35673 times)

Zoran

  • Hero Member
  • *****
  • Posts: 1829
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: FPC 3.2.0 Released !
« Reply #60 on: July 13, 2020, 08:33:50 am »
Something 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

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: FPC 3.2.0 Released !
« Reply #61 on: July 13, 2020, 09:25:27 am »
Something 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

  • Newbie
  • Posts: 1
Re: FPC 3.2.0 Released !
« Reply #62 on: July 13, 2020, 05:32:14 pm »
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

  • Hero Member
  • *****
  • Posts: 4219
Re: FPC 3.2.0 Released !
« Reply #63 on: July 13, 2020, 06:24:37 pm »
What 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.
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

Jackofall1

  • Newbie
  • Posts: 4
Re: FPC 3.2.0 Released !
« Reply #64 on: July 20, 2020, 11:40:23 pm »
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

  • Hero Member
  • *****
  • Posts: 3197
Re: FPC 3.2.0 Released !
« Reply #65 on: July 20, 2020, 11:56:22 pm »
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
« Last Edit: July 20, 2020, 11:58:00 pm by winni »

Jackofall1

  • Newbie
  • Posts: 4
Re: FPC 3.2.0 Released !
« Reply #66 on: July 21, 2020, 12:08:08 am »
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

  • Hero Member
  • *****
  • Posts: 836
Re: FPC 3.2.0 Released !
« Reply #67 on: July 21, 2020, 01:55:55 am »
Please report it to BitDefender. They have necessary means to identify if it is a false positive or not.

ASBzone

  • Hero Member
  • *****
  • Posts: 678
  • Automation leads to relaxation...
    • Free Console Utilities for Windows (and a few for Linux) from BrainWaveCC
Re: FPC 3.2.0 Released !
« Reply #68 on: July 21, 2020, 05:38:25 am »
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


Most of them fail in the heuristics analysis functionality.   
-ASB: https://www.BrainWaveCC.com/

Lazarus v2.2.7-ada7a90186 / FPC v3.2.3-706-gaadb53e72c
(Windows 64-bit install w/Win32 and Linux/Arm cross-compiles via FpcUpDeluxe on both instances)

My Systems: Windows 10/11 Pro x64 (Current)

Seenkao

  • Hero Member
  • *****
  • Posts: 546
    • New ZenGL.
Re: FPC 3.2.0 Released !
« Reply #69 on: November 27, 2020, 07:15:23 am »
День добрый!
Я зачастую использую 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.
Rus: Стремлюсь к созданию минимальных и достаточно быстрых приложений.

Eng: I strive to create applications that are minimal and reasonably fast.
Working on ZenGL

ccrause

  • Hero Member
  • *****
  • Posts: 845
Re: FPC 3.2.0 Released !
« Reply #70 on: November 27, 2020, 10:54:32 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

  • Hero Member
  • *****
  • Posts: 546
    • New ZenGL.
Re: FPC 3.2.0 Released !
« Reply #71 on: November 27, 2020, 01:30:48 pm »
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.
Rus: Стремлюсь к созданию минимальных и достаточно быстрых приложений.

Eng: I strive to create applications that are minimal and reasonably fast.
Working on ZenGL

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: FPC 3.2.0 Released !
« Reply #72 on: November 27, 2020, 03:36:10 pm »
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.

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.

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.

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

  • Hero Member
  • *****
  • Posts: 546
    • New ZenGL.
Re: FPC 3.2.0 Released !
« Reply #73 on: November 27, 2020, 03:59:48 pm »
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.

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).
Rus: Стремлюсь к созданию минимальных и достаточно быстрых приложений.

Eng: I strive to create applications that are minimal and reasonably fast.
Working on ZenGL

PascalDragon

  • Hero Member
  • *****
  • Posts: 5446
  • Compiler Developer
Re: FPC 3.2.0 Released !
« Reply #74 on: November 28, 2020, 11:11:32 am »
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).

As long as it doesn't show a bug nothing will be changed there, cause that is how it's designed to be.

 

TinyPortal © 2005-2018