A branch was made for a future series of 3.2.x FPC releases. A first releaseof this branch is still months away, but the moment to test the compatibilityof your codebases with the future FPC is _NOW_!, while there is still timeto do something about it.

The svn designation of this fixes branch is branches/fixes_3_2

As a consequence, trunk will be updated to version 3.3.1, some people might have to update their scripts.

gives no warning at 3.0.4 but with the latest trunk it gives"unit1.pas(36,14) Warning: Local variable "a" of a managed type does not seem to be initialized" at line with SetLength, which is silly since SetLength itself is initialization. SetLength passes parameter by refrence (var) but it is same in 3.0.4 and 3.1.1.

A branch was made for a future series of 3.2.x FPC releases. A first releaseof this branch is still months away, but the moment to test the compatibilityof your codebases with the future FPC is _NOW_!, while there is still timeto do something about it.

The svn designation of this fixes branch is branches/fixes_3_2

As a consequence, trunk will be updated to version 3.3.1, some people might have to update their scripts.

gives no warning at 3.0.4 but with the latest trunk it gives"unit1.pas(36,14) Warning: Local variable "a" of a managed type does not seem to be initialized" at line with SetLength, which is silly since SetLength itself is initialization. SetLength passes

No. If you followed the bug report on Mantis.Case in point is that setlength() does NOT guarantee its values are initialized to a default. It just reserves space for a given number of elements. Even if the compiler MAY internally do something more.As explained in the bug report and the follow ups it is trivial to actually initialize. (different syntax for objfpc and delphi mode, beware)And as far as I can see there is no need for a fix.

Logged

inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.

gives no warning at 3.0.4 but with the latest trunk it gives"unit1.pas(36,14) Warning: Local variable "a" of a managed type does not seem to be initialized" at line with SetLength, which is silly since SetLength itself is initialization. SetLength passes parameter by refrence (var) but it is same in 3.0.4 and 3.1.1.

in oder to suppress the unwanted warnings. Problem is that it does not work with -B, seehttps://bugs.freepascal.org/view.php?id=34349I agree that the warnings are wrong or at least sub optimal. Initializing the managed variables in code produces quite heavy redundant instructions:

This is only information for fpc-developer. I don't know if is it bug or new feature. I never used multithreading on fpc, I detected it as I look some examples here:http://forum.lazarus-ide.org/index.php/topic,43005.msg301598Maybe you should put this on your changed list, so the developer can change their code.

@marco I don't know anything about multithreading and IsMultiThread variable in fpc.I wanted only inform the developers and users of fpc.In example from above and in ibx-examples with fpc 3.0.2 IsMultiThread is in OnFormCreate true but with fpc 3.2.0. it is false.

When this normal is then it is okay.According to documentation the behavior in version 3.2.0 is more correct.Maybe you should write in fpc 3.2.0 release notes something like "IsMultiThreads value is more accurate now", to inform the developers.

Edit 1:Maybe Toni (author of ibx) and others need a variable like IsMultiThreadSupported.After reading the documentation and thinking about, I must say the behavior in 3.0.2 is wrong.

Note the behavior on different platforms is slightly different (has always been the case).- On unixes (Posix), IsMultiThread is set when you include cthreads in the uses clause, assuming that if you include a threadmanager it is your intention to have a multithreaded application..- On Windows, IsMultiThread is set when a thread is actually used (except from the bare Windows API functions, you need to set IsMultiThread by hand). For Windows there is a minimal Threadmanager included in the system unit.- On other platforms it may varyThese differences are wholly caused by the differences in the underlying OS.The specific behavior is mainly documented in the sources but the above is also documented in the official documentation.See https://www.freepascal.org/docs-html/current/prog/progch10.html#progse43.html

Note that currently some work is going on in trunk related to thread local storage and as always implementation details need not be documented if there are no side effects.

In general don't assume anything about threading internals and don't assume the behavior is equivalent to e.g. Delphi.And more broadly speaking I am one of those people that believe that a programmer that uses threading requires a license. Relatively few people qualify.....in any language...

« Last Edit: November 09, 2018, 08:43:09 pm by Thaddy »

Logged

inline variables like in D10.3 are a bit like Brexit: if you are given the wrong information it sounds like a good idea. Every kid loves candy, but it makes you fat and your teeth will disappear.