Re: [fpc-devel] ref count types / threadsave question

On 02/01/2019 21:52, Jonas Maebe wrote: This is a different issue. Managed types are indeed only threadsafe as long as there is no race condition that could cause their refcount to become zero at some point. The issue I was talking about is the fact that atomic operations do function as glo

Re: [fpc-devel] ref count types / threadsave question

On 02/01/19 21:46, Martin Frb wrote: On 02/01/2019 21:22, Benito van der Zander wrote: Hi, but if another core can do anything to the string, the refcount should already be 2, one for this core and one for the other core, should it not? No: // global var var   Foo: String; // main thread F

Re: [fpc-devel] ref count types / threadsave question

On 02/01/2019 21:22, Benito van der Zander wrote: Hi, but if another core can do anything to the string, the refcount should already be 2, one for this core and one for the other core, should it not? No: // global var var   Foo: String; // main thread Foo := getsomestring_with_refcount_1();

Re: [fpc-devel] ref count types / threadsave question

On 02/01/19 21:22, Benito van der Zander wrote: but if another core can do anything to the string, the refcount should already be 2, one for this core and one for the other core, should it not? The problem is that the different cores may see different values. Core 1 could see that the refcoun

Re: [fpc-devel] ref count types / threadsave question

Hi, but if another core can do anything to the string, the refcount should already be 2, one for this core and one for the other core, should it not? UniqueString has such a test: Function fpc_ansistr_Unique(Var S : Pointer): Pointer; [Public,Alias : 'FPC_ANSISTR_UNIQUE']; compilerproc; inli

Re: [fpc-devel] ref count types / threadsave question

On 02/01/19 20:08, Martin wrote: If a local string var has a refcount of 1, then it can not be accessed by any other thread. Therefore it needs no lock for decreasing the ref. You would need a full memory barrier before checking whether the reference count is one, otherwise it could have been

[fpc-devel] ref count types / threadsave question

Below is for ansistring, but same should apply to dyn arrays. Procedure fpc_AnsiStr_Incr_Ref (S : Pointer); [Public,Alias:'FPC_ANSISTR_INCR_REF'];  compilerproc; inline; Begin   If S=Nil then     exit; // anytime after this line: // other thread, and only ref-count holder calls fpc_ansistr_decr

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

On Wed, 2 Jan 2019, Martok wrote: Am 02.01.2019 um 17:56 schrieb Michael Van Canneyt: The compiler can prove that since the methods are private. It can see no explicit calls are generated for it. I thought so too, but even with added explicit calls, there is no warning. Plus, it could only

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

On 02/01/19 17:41, Martok wrote: Wait - why does that code not raise a 5033 "Function Result does not seem to be set"? Add a second property "Property MyOtherString : String Index 2 Read GetString;", and now its provably wrong. No warning. This seems wrong, considering what we just talked about o

Re: [fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).

Hi, On Wed, 2 Jan 2019, Olivier Coursière wrote: >> Should linking without libc (as in, libroot) be supported? > I have only maintained the libc/libroot part since the beginning of > Haiku port ten years ago. Well, we do have other libc-only ports, like the macOS/Darwin version. It's best to re

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Am 02.01.2019 um 17:56 schrieb Michael Van Canneyt: > The compiler can prove that since the methods are private. > It can see no explicit calls are generated for it. I thought so too, but even with added explicit calls, there is no warning. Plus, it could only reason for this class if it was stric

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Am 02.01.2019 um 11:30 schrieb Florian Klämpfl: > The compiler is for speed reasons not compiled with $R+/$O+, so the safety > else clause have its purpose, but they should > throw an internal error instead. And here we are at that other issue again. There is absolutely no guarantee the safety cla

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

On Wed, 2 Jan 2019, Martok wrote: Am 02.01.2019 um 11:19 schrieb Michael Van Canneyt: Consider the following: Type TMyClass = class Private function GetString(AIndex: Integer): string; Published Property MyString : String Index 1 Read GetString; end; function TMyClass

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

On 1/2/2019 2:18 AM, Sven Barth via fpc-devel wrote: Am Mi., 2. Jan. 2019, 09:44 hat Martok > geschrieben: * in ISO mode, there are 2 solutions: in Standard Pascal, not covering the entire type is a compile-time error. In Extended Pascal, this is a

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Wait - why does that code not raise a 5033 "Function Result does not seem to be set"? Add a second property "Property MyOtherString : String Index 2 Read GetString;", and now its provably wrong. No warning. This seems wrong, considering what we just talked about on fpc-pascal. Because there i

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Am 02.01.2019 um 11:19 schrieb Michael Van Canneyt: > Consider the following: > > Type >TMyClass = class >Private > function GetString(AIndex: Integer): string; >Published > Property MyString : String Index 1 Read GetString; >end; > > function TMyClass.GetString(AIndex:

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Am 02.01.2019 um 11:06 schrieb Bart: > So now I will have to add a useless else statement for every case > statement that uses e.g. integers, Well, as Jonas argues on fpc-pascal, you are supposed to add useless statements anyway, which the compiler will then 100% remove... j/k. In all seriousness

Re: [fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).

 Hi, Le 31/12/2018 à 19:16, Olivier Coursière via fpc-devel a écrit : if you want, I can integrate those changes into trunk for you. Thank you for the offer but i should have some free time in the next two days. I should already have the change in a 3.0.4 branch. It should be easy to port to t

Re: [fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).

Hi, Le 01/01/2019 à 18:01, Karoly Balogh (Charlie/SGR) a écrit : On Mon, 31 Dec 2018, Karoly Balogh (Charlie/SGR) wrote: Not really. I have investigated what need to be done for x86-64 port but the assembly part (cprt0.as) was enough to dissuade me so far ;-) Other CPUs will require a working

Re: [fpc-devel] Proposal to adapt search patch under Haiku using a target specific option (-WH).

Hi, Le 02/01/2019 à 07:43, Karoly Balogh (Charlie/SGR) a écrit : Hi, On Tue, 1 Jan 2019, Karoly Balogh (Charlie/SGR) wrote: (Not sure if Olivier is on the list, so keep cc:-ing him...) Yes, i am on this list ;-) So, bottom line, see the following patch: http://charlie.amigaspirit.hu/temp/

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

On Wed, 2 Jan 2019, Mattias Gaertner via fpc-devel wrote: > Warnings can always be disabled by {$warn NR off} or - I believe - a > command line switch. > One could also decide to have it be a default off warning for the > non ISO modes (FPC, Delphi, MacPas) like some of the string > conversion

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

On Wed, 2 Jan 2019 12:05:17 +0100 (CET) Michael Van Canneyt wrote: > On Wed, 2 Jan 2019, Sven Barth via fpc-devel wrote: > > > Am Mi., 2. Jan. 2019, 11:08 hat Bart > > geschrieben: > >> On Wed, Jan 2, 2019 at 9:44 AM Martok > >> wrote: > >>> - If a case statement on an ordinal does not conta

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

On Wed, 2 Jan 2019, Sven Barth via fpc-devel wrote: Am Mi., 2. Jan. 2019, 11:08 hat Bart geschrieben: On Wed, Jan 2, 2019 at 9:44 AM Martok wrote: - If a case statement on an ordinal does not contain labels for all values of the ordinal, and no else statement is given, raise a new warn

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

On Wed, Jan 2, 2019 at 11:22 AM Florian Klämpfl wrote: > Which ordinal changes in FPC its range depending on the architecture? Integer is not the same range on 16-bit platform IIRC? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org h

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Il 01/01/2019 22:10, Martok ha scritto: - If a case statement on an ordinal does not contain labels for all values of the ordinal, and no else statement is given, raise a new warning (W6059). This is actually defined as an error in ISO7185 and a dynamic-violation in IEC10206. * in ISO mode, t

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Am 01.01.2019 um 22:10 schrieb Martok: > > * Building the compiler itself cycles with -Sew, so it bails on the first > occurrence of one of these issues - turns out they're all over the place. > However... I think the warnings are correct and expose imperfect code here. > Take this example (one o

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

>> - If a case statement on an ordinal does not contain labels for all values of >> the ordinal, and no else statement is given, raise a new warning (W6059). >> This >> is actually defined as an error in ISO7185 and a dynamic-violation in >> IEC10206. > So now I will have to add a useless else s

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Am 02.01.2019 um 11:06 schrieb Bart: > On Wed, Jan 2, 2019 at 9:44 AM Martok wrote: > >> - If a case statement on an ordinal does not contain labels for all values of >> the ordinal, and no else statement is given, raise a new warning (W6059). >> This >> is actually defined as an error in ISO718

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Am Mi., 2. Jan. 2019, 11:08 hat Bart geschrieben: > On Wed, Jan 2, 2019 at 9:44 AM Martok wrote: > > > - If a case statement on an ordinal does not contain labels for all > values of > > the ordinal, and no else statement is given, raise a new warning > (W6059). This > > is actually defined as a

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

On Tue, 1 Jan 2019, Martok wrote: Hi all, The attached patch adds two messages inspired by C compiler's -Wswitch-enum and -Wcovered-switch-default. Building on the recent label count refactoring, this was fairly straightforward. - If a case statement on an ordinal does not contain labels for

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Am Mi., 2. Jan. 2019, 09:44 hat Martok geschrieben: > * in ISO mode, there are 2 solutions: in Standard Pascal, not covering the > entire type is a compile-time error. In Extended Pascal, this is a runtime > error. Which one is followed usually? > ISO and Extended Pascal are handled as two separ

Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

On Wed, Jan 2, 2019 at 9:44 AM Martok wrote: > - If a case statement on an ordinal does not contain labels for all values of > the ordinal, and no else statement is given, raise a new warning (W6059). This > is actually defined as an error in ISO7185 and a dynamic-violation in > IEC10206. So no

[fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements

Hi all, The attached patch adds two messages inspired by C compiler's -Wswitch-enum and -Wcovered-switch-default. Building on the recent label count refactoring, this was fairly straightforward. - If a case statement on an ordinal does not contain labels for all values of the ordinal, and no else