Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 31.08.2023 17:54, Tomas Hajny via fpc-devel wrote: On 2023-08-31 17:08, Ondrej Pokorny via fpc-devel wrote: :) We are not at the finish yet. Positive outcome will be when it gets fixed in the compiler source. Yes, I know. I checked your patch briefly now and I don't like the fact

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

Am 31.08.2023 um 9:59 schrieb Tomas Hajny via fpc-devel: On 2023-08-30 23:38, Ondrej Pokorny via fpc-devel wrote: Am 30.08.2023 um 20:21 schrieb Ondrej Pokorny via fpc-devel: Having seen the outputs, I think that the compiler just ignores the source file encoding for {$MESSAGE} and {$NOTE

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

Am 30.08.2023 um 20:21 schrieb Ondrej Pokorny via fpc-devel: On 30.08.2023 17:35, Tomas Hajny via fpc-devel wrote: On 2023-08-30 17:23, Ondrej Pokorny via fpc-devel wrote: Sorry to bother you with something as trivial: is your t2.pas file really encoded in UTF-8? Because if I compile an ANSI

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 30.08.2023 17:35, Tomas Hajny via fpc-devel wrote: On 2023-08-30 17:23, Ondrej Pokorny via fpc-devel wrote: Sorry to bother you with something as trivial: is your t2.pas file really encoded in UTF-8? Because if I compile an ANSI file with the {$codepage utf8} declaration, then I get

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 30.08.2023 17:04, Tomas Hajny via fpc-devel wrote: On 2023-08-30 16:32, Ondrej Pokorny via fpc-devel wrote: If you mean https://stackoverflow.com/questions/56419639/what-does-beta-use-unicode-utf-8-for-worldwide-language-support-actually-do, then no, I don't have this option checked

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 30.08.2023 17:04, Tomas Hajny via fpc-devel wrote: On 2023-08-30 16:32, Ondrej Pokorny via fpc-devel wrote: If you mean https://stackoverflow.com/questions/56419639/what-does-beta-use-unicode-utf-8-for-worldwide-language-support-actually-do, then no, I don't have this option checked

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 30.08.2023 16:23, Tomas Hajny via fpc-devel wrote: On 2023-08-30 15:26, Ondrej Pokorny via fpc-devel wrote: On 30.08.2023 13:49, Mattias Gaertner via fpc-devel wrote: On 30.08.23 12:04, Tomas Hajny via fpc-devel wrote: On 2023-08-28 15:53, Ondrej Pokorny via fpc-devel wrote: [...] Your

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

On 30.08.2023 13:49, Mattias Gaertner via fpc-devel wrote: On 30.08.23 12:04, Tomas Hajny via fpc-devel wrote: On 2023-08-28 15:53, Ondrej Pokorny via fpc-devel wrote: [...] Your output is different from mine (using a freshly compiled trunk compiler): Free Pascal Compiler version 3.3.1 [2023

[fpc-devel] fpc compiler wrong encoding in console output on Windows

Hello, when compiling a program with fpc on Windows, fpc seems to have the console output encoding wrong. Example program (I am using "ä" because I am on german OS, so "ä" is in my DOS Latin and also in my ANSI codepage): {$codepage utf8} program TestNote; begin {$note ä} end. The console

Re: [fpc-devel] Memory leak: bug ot as designed?

Nice one :) I am also interested in the answer. IMO it is a bug because the code is valid - https://www.freepascal.org/docs-html/ref/refse10.html FYI: Delphi doesn't create a memory leak. Ondrej ___ fpc-devel maillist -

Re: [fpc-devel] Unexpected "Range check error while evaluating constants" when compiling for Win64

On 12.02.2023 23:08, Bart via fpc-devel wrote: On Sun, Feb 12, 2023 at 10:47 PM Jonas Maebe via fpc-devel wrote: Afaik it's because "default" doesn't support qword values, iirc because of (at least old) Delphi compatibility. OK, I removed the "default". Theoretically would that lead to

Re: [fpc-devel] Question on constref

On 02.02.2023 14:22, Sven Barth via fpc-devel wrote: Only because you can't see a reason for it doesn't mean that it doesn't exist. That is exactly why I asked :) Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Question on constref

On 02.02.2023 12:19, Marco van de Voort via fpc-devel wrote: On 2-2-2023 12:00, Ondrej Pokorny via fpc-devel wrote: The only disadvantage is that you get a FreeAndNil copy for every type you pass into the parameter (?) Are they actually made global ? Will two freeandnil in different units use

Re: [fpc-devel] Question on constref

On 02.02.2023 12:25, Mattias Gaertner via fpc-devel wrote: On Thu, 2 Feb 2023 12:00:31 +0100 Ondrej Pokorny via fpc-devel wrote: [...] Delphi cannot do it. FPC rocks! +1 The only disadvantage is that you get a FreeAndNil copy for every type you pass into the parameter (?) Do we want

Re: [fpc-devel] Question on constref

On 02.02.2023 11:00, Michael Van Canneyt via fpc-devel wrote: In userspace, the best seems Function FreeAndNil(Obj : T) : T; begin   Obj.Free;   Result:=Nil; end; With automatic type inference for generics, this allows you to do A:=FreeAndNil(A); Michael, bringing your idea to the next

Re: [fpc-devel] Question on constref

On 02.02.2023 10:22, Michael Van Canneyt via fpc-devel wrote: On Thu, 2 Feb 2023, Ondrej Pokorny via fpc-devel wrote: On 02.02.2023 10:15, Michael Van Canneyt via fpc-devel wrote: On Thu, 2 Feb 2023, Ondrej Pokorny via fpc-devel wrote: I myself cannot think of any real use case of constref

Re: [fpc-devel] Question on constref

On 02.02.2023 10:15, Michael Van Canneyt via fpc-devel wrote: On Thu, 2 Feb 2023, Ondrej Pokorny via fpc-devel wrote: I myself cannot think of any real use case of constref other than hacks like the FreeAndNil in recent Delphi versions: procedure FreeAndNil(const [ref] Obj: TObject

Re: [fpc-devel] Question on constref

On 02.02.2023 07:42, Sven Barth via fpc-devel wrote: The case when you *need* a constant reference. Case in point: the passing of TGuid in IInterface.QueryInterface. Delphi code relies on it being a reference, but “const” does not guarantee that for all platforms. Maybe I am missing

Re: [fpc-devel] Function to find if IP address is local

On 09.01.2023 09:08, Michael Van Canneyt wrote: On Mon, 9 Jan 2023, Ondrej Pokorny via fpc-devel wrote: Is there a routine in RTL to find out if a given IPv4 address is from the private address range (10.* etc)? No, not to my knowledge. Feel free to add it somewhere in fcl-net. Here

[fpc-devel] Function to find if IP address is local

Hello! Is there a routine in RTL to find out if a given IPv4 address is from the private address range (10.* etc)? Thanks Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] threads vs widestringmanager / crash

On 20.12.2022 21:12, Sven Barth via fpc-devel wrote: Please stop focusing on the WideString manager. That is simply a symptom. The real cause is that a thread is created where there shouldn't be one and under normal circumstance there indeed will be none: - if the initialization is executed as

Re: [fpc-devel] threads vs widestringmanager / crash

On 19.12.2022 09:51, Michael Van Canneyt via fpc-devel wrote: If you can prepare a simple sample program that shows the problem, I can try to look into it. Maybe a fresh pair of eyes sees more than one pair of eyes? You don't need a special sample program. Every console application on Windows

Re: [fpc-devel] threads vs widestringmanager / crash

On 19.12.2022 07:42, Sven Barth via fpc-devel wrote: The RTL assumes that it does not have to deal with threads during the initialization of the System unit. So even if the symptom of the crash is fixed in that location it isn't said that something else might crash or that in the future code

Re: [fpc-devel] threads vs widestringmanager / crash

I have the same problem. It is very annoying because programs crash quite often when run in a debugger (on Windows). I solved it with the attached patch - I added these lines to procedure OpenStdIO(var f:text;mode:longint;hdl:thandle);   {$if defined(FPC_HAS_CPSTRING) and

Re: [fpc-devel] Sorting tests

Am 29.11.2022 um 14:25 schrieb Sven Barth via fpc-devel: For such a comparison function the issue is indeed in the comparison function, but Nikolay also mentioned "ais the case for equal elements. I assume this was some kind of typo or reasoning error because "acompare function is correct.

Re: [fpc-devel] Sorting tests

Am 29.11.2022 um 11:08 schrieb Sven Barth via fpc-devel: J. Gareth Moreton via fpc-devel schrieb am Di., 29. Nov. 2022, 10:09: Surely that's a bug in the comparison functions that should be fixed and not something that can be blamed on introsort.  If a comparison function

Re: [fpc-devel] Just need to double check the size of Integer

Am 24.11.2022 um 14:44 schrieb Tomas Hajny via fpc-devel: On 2022-11-24 14:25, Ondrej Pokorny via fpc-devel wrote: Am 24.11.2022 um 14:15 schrieb Marco van de Voort via fpc-devel: On 24-11-2022 14:13, J. Gareth Moreton via fpc-devel wrote: I just need to double-check something.  Under CPU16

Re: [fpc-devel] Just need to double check the size of Integer

Am 24.11.2022 um 14:15 schrieb Marco van de Voort via fpc-devel: On 24-11-2022 14:13, J. Gareth Moreton via fpc-devel wrote: I just need to double-check something.  Under CPU16, SizeInt and SizeUInt are declared as follows:   SizeInt = Integer;   SizeUInt = Word; Is Integer 16-bit in this

Re: [fpc-devel] Just need to double check the size of Integer

Am 24.11.2022 um 14:15 schrieb Marco van de Voort via fpc-devel: On 24-11-2022 14:13, J. Gareth Moreton via fpc-devel wrote: I just need to double-check something.  Under CPU16, SizeInt and SizeUInt are declared as follows:   SizeInt = Integer;   SizeUInt = Word; Is Integer 16-bit in this

Re: [fpc-devel] Compile error with actual FPC main and Lazarus main

Am 28.09.2022 um 18:53 schrieb Gabor Boros via fpc-devel: 2022.09.28. 17:43 keltezéssel, Ondrej Pokorny via fpc-devel írta: Try a clean build. Ondrej Clean build is ok. The problem appears when use "Build Lazarus with Profile: Normal IDE". That is quite normal. If you see s

Re: [fpc-devel] Compile error with actual FPC main and Lazarus main

Am 28.09.2022 um 12:53 schrieb Gabor Boros via fpc-devel: Hi All, With actual FPC (123f196d) and Lazarus (11bb7ce4) got the below error. Any idea? sourcefilemanager.pas(311,1) Error: Compilation raised exception internally Try a clean build. Ondrej

[fpc-devel] Fwd: [Lazarusdev] Moving issue 39853 to FPC project

Hello it looks like only people with FPC developer status can move issues to the FPC project. Therefore I forward the request to fpc-devel. Ondrej Weitergeleitete Nachricht Betreff:[Lazarusdev] Moving issue 39853 to FPC project Datum: Thu, 18 Aug 2022 03:51:33 +0300

Re: [fpc-devel] Gaps in a non-contiguous enum

Am 16.08.2022 um 13:19 schrieb Michael Van Canneyt via fpc-devel: On Tue, 16 Aug 2022, Ondrej Pokorny via fpc-devel wrote: --- code end Run it in Delphi and FPC and compare the outputs: Delphi output: PropCount: 0 Property info is null FPC output: PropCount: 1 Property name: Fruit Property

Re: [fpc-devel] Gaps in a non-contiguous enum

Am 16.08.2022 um 09:37 schrieb Michael Van Canneyt via fpc-devel: On Tue, 16 Aug 2022, Juha Manninen via fpc-devel wrote: On Thu, Aug 11, 2022 at 9:37 PM Martin Frb via fpc-devel < fpc-devel@lists.freepascal.org> wrote: fpc code is still "unexpected". It takes into account the MinValue type

Re: [fpc-devel] tkLString vs tkAString

On 30.11.2021 13:43, Marc Weustink via fpc-devel wrote: On 30-11-2021 13:37, Michael Van Canneyt via fpc-devel wrote: On Tue, 30 Nov 2021, Marc Weustink via fpc-devel wrote: Hi, I ran into an issue with a piece of ported Delphi (6) code and RTTI. Part of the Delphi code was based on strings

Re: [fpc-devel] OpenSSL v1.1.x DLL loading / Bug 37137

On 28.09.2020 16:05, Michael Van Canneyt wrote: On Mon, 28 Sep 2020, Ondrej Pokorny via fpc-devel wrote: On 28.09.2020 15:34, Michael Van Canneyt via fpc-devel wrote: I made some time for this, it's checked in with revision 46987. Note that this revision also enables support for LibreSSL

Re: [fpc-devel] OpenSSL v1.1.x DLL loading / Bug 37137

On 28.09.2020 15:34, Michael Van Canneyt via fpc-devel wrote: I made some time for this, it's checked in with revision 46987. Note that this revision also enables support for LibreSSL (or whatever it is called) versions on linux/mac systems. Thank you for your patch, and I'm sorry that it

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

On 27.09.2020 23:45, Travis Siegel via fpc-devel wrote: On 9/27/2020 3:50 PM, Florian Klämpfl via fpc-devel wrote: - there are little libraries being really IEEE compliant for float128 - if they are IEEE compliant, their license does not allow to use the code in the FPC rtl. I don't

Re: [fpc-devel] TThread.RemoveQueuedEvents

On 25.09.2020 03:30, Martin via fpc-devel wrote: Wath is in the following indented? The doc says https://www.freepascal.org/docs-html/rtl/classes/tthread.removequeuedevents.html all calls to the given method are removed. However there may be more than one way to read this. aMethod:

Re: [fpc-devel] about #0035991, fpc 3.2.1 still crash lazarus 2.0.10, 2.0.11

Hello Bald, it is not possible to support the latest FPC trunk in already released Lazarus versions (2.0.10). If you want some bug fixes to be merged into the stable branch (currently 2.0.11), you can list the revisions here: https://wiki.freepascal.org/Lazarus_2.0_fixes_branch I did it

Re: [fpc-devel] ftfont and FreeType

I am not 100% sure, but some freetype.dll versions can depend on zlib1.dll. I.e. you need to copy zlib1.dll to the exe directory as well. Actually I just found an info about it: https://wiki.freepascal.org/FPReport_FAQ (see Lazarus does not start anymore in Windows). Ondrej On 17.07.2020

[fpc-devel] AS-IS for enums

Hello Florian, as we spoke I checked the patch for IS operators for enumerations. I also added int64/dword value compatibility that was missing in the last patches. There is still some bug/issue left. The objfpc mode shows warnings like this: test_as_is_1.lpr(51,8) Warning: Expectloc is

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

On 03.01.2020 11:09, Michael Van Canneyt wrote: I also think it is very hypothetical, and not a problem unless you want to use the same stream in Delphi and FPC. Well, you have my blessing for the soPreserveBOM :) Added in r43848. I'll check how the FPC documentation works and try to add it

Re: [fpc-devel] A more fundamental problem Re: i36507

On 03.01.2020 11:00, J. Gareth Moreton wrote: This was not a new property or a recent change to the Lazarus sources though. It was a recent change in FPC RTL sources: r43841. I was using an old revision of Lazarus to test optimisations on, and had been doing fine with it until I discovered

Re: [fpc-devel] A more fundamental problem Re: i36507

On 03.01.2020 10:45, J. Gareth Moreton wrote: Given the "illegal qualifier" errors that appeared, I'm guessing the issue is that "Options" is also a property of the THistoryList class as well as a local variable.  Technically speaking though, this is a regression unless it's to be documented

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

On 03.01.2020 10:14, Michael Van Canneyt wrote: On Fri, 3 Jan 2020, Ondrej Pokorny wrote: On 03.01.2020 00:35, Werner Pamler wrote: Am 02.01.2020 um 20:10 schrieb Ondrej Pokorny: TStrings.SaveTo*() writes BOM by default. Formerly the BOM was not written. There is also the problem

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

On 03.01.2020 00:35, Werner Pamler wrote: Am 02.01.2020 um 20:10 schrieb Ondrej Pokorny: TStrings.SaveTo*() writes BOM by default. Formerly the BOM was not written. There is also the problem that currently it is not possible, without further action, to retain the BOM state of a file loaded

Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)

It should be fixed with r43846. You may need to delete fpmake.exe and fpmake.o to make sure they are recompiled. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)

On 02.01.2020 20:34, Bart via fpc-devel wrote: After revision 43841 make all in the root fails Thanks - I fixed this one. But there seems to be another problem. I am on it now. Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

On 27.12.2019 12:01, Ondrej Pokorny wrote: On 27.12.2019 10:40, Michael Van Canneyt wrote: Yes, indeed. Therefore I suggested * TEncoding.Default for the DefaultSystemCodePage variable and * TEncoding.ANSI for the system encoding. Currently we have * TEncoding.SystemEncoding

Re: [fpc-devel] TStrings and BOM

On 02.01.2020 14:58, Michael Van Canneyt wrote: On Thu, 2 Jan 2020, Bart via fpc-devel wrote: On Thu, Jan 2, 2020 at 12:12 PM Michael Van Canneyt wrote: In Delphi it doesn't matter where the encoding comes from. If writeBOM is true and there is a preamble for the encoding (whatever it

Re: [fpc-devel] TStrings and BOM

On 02.01.2020 0:51, Ondrej Pokorny wrote: On 01.01.2020 23:59, Werner Pamler wrote: Am 01.01.2020 um 17:01 schrieb Ondrej Pokorny: Isn't the TStrings.WriteBOM property good enough? Why to have yet another not-very-useful overload? To be honest I think Bart's idea of making the BOM

Re: [fpc-devel] TStrings and BOM

On 01.01.2020 23:59, Werner Pamler wrote: Am 01.01.2020 um 17:01 schrieb Ondrej Pokorny: Isn't the TStrings.WriteBOM property good enough? Why to have yet another not-very-useful overload? To be honest I think Bart's idea of making the BOM an optional parameter of the Save methods appears

Re: [fpc-devel] TStrings and BOM

On 01.01.2020 13:00, Bart via fpc-devel wrote: On Wed, Jan 1, 2020 at 12:25 PM Bart wrote: By all means, patches welcome. Patch attached. For completeness I could implement also SaveToStream(AStream, AWriteBom) and SaveToFile(FileName, AWriteBom). // code begin // -Procedure

Re: [fpc-devel] TStrings and BOM

On 31.12.2019 18:37, Michael Van Canneyt wrote: On Tue, 31 Dec 2019, Bart via fpc-devel wrote: Would introducing a overload of TStrings.SaveTo* with a 3rd parameter to controle the writing of the BOM be acceptable? By all means, patches welcome. Isn't the TStrings.WriteBOM property good

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

On 27.12.2019 10:40, Michael Van Canneyt wrote: Yes, indeed. Therefore I suggested * TEncoding.Default for the DefaultSystemCodePage variable and * TEncoding.ANSI for the system encoding. Currently we have * TEncoding.SystemEncoding for the DefaultSystemCodePage variable and * both

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

On 26.12.2019 23:42, Marco van de Voort wrote: Op 12/26/2019 om 9:12 PM schreef Ondrej Pokorny: In Delphi TEncoding.ANSI and TEncoding.Default are actually different. See: http://docwiki.embarcadero.com/Libraries/Rio/en/System.SysUtils.TEncoding.Default http://docwiki.embarcadero.com

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

On 27.12.2019 0:19, Michael Van Canneyt wrote: On Thu, 26 Dec 2019, Ondrej Pokorny wrote: On 26.12.2019 19:29, Michael Van Canneyt wrote: So no, I don't think these need to be changed/merged. What IMO can be discussed is which of these 2 need to be used as the default codepage in other code

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

On 26.12.2019 19:29, Michael Van Canneyt wrote: So no, I don't think these need to be changed/merged. What IMO can be discussed is which of these 2 need to be used as the default codepage in other code. It should then resolve the problems that appear, I think. That would be possible as well.

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

On 26.12.2019 17:02, Mattias Gaertner via fpc-devel wrote: On Thu, 26 Dec 2019 16:55:04 +0100 Ondrej Pokorny wrote: On 26.12.2019 16:41, Mattias Gaertner via fpc-devel wrote: On Thu, 26 Dec 2019 16:15:03 +0100 Ondrej Pokorny wrote: Hello, a lot of people have a problem

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

On 26.12.2019 16:41, Mattias Gaertner via fpc-devel wrote: On Thu, 26 Dec 2019 16:15:03 +0100 Ondrej Pokorny wrote: Hello, a lot of people have a problem with the TStrings.LoadFrom*() changes when TEncoding support was added. Currently, the no-encoding overloads of TStrings.LoadFrom

[fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

Hello, a lot of people have a problem with the TStrings.LoadFrom*() changes when TEncoding support was added. Currently, the no-encoding overloads of TStrings.LoadFrom*() and TStrings.SaveTo*() use the TEncoding.Default, which is WIN-ANSI and not DefaultSystemCodePage. Before the changes,

Re: [fpc-devel] TFPList / TList Sort with Context parameter

I needed to get things working so I could not wait for an answer any longer. I posted a patch: https://bugs.freepascal.org/view.php?id=35962 Best Ondrej ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] TFPList / TList Sort with Context parameter

On 12.08.2019 13:02, Ondrej Pokorny wrote: If this is not possible (which I think it is not), will a patch be accepted that adds these methods to TFPList/TList?:     procedure Sort(Compare: TListSortComparer_Context);     procedure Sort(Compare: TListSortComparer_Context; SortingAlgorithm

[fpc-devel] TFPList / TList Sort with Context parameter

Hello! I see that sortbase.pp has prepared sorting functionality with context (=custom parameter) that I need to use. See TSortingAlgorithm.PtrListSorter_ContextComparer and QuickSort_PtrList_Context. But I don't know how to use them within TList because TFPList / TList doesn't publish any

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 13.07.2019 21:26, Michael Van Canneyt wrote: I think all sides have now been reviewed to the point of boring or annoying each other almost to death, and we finally need to decide on whether the patch is applied, and if so, which parts of it. That would be great. I have been waiting for

Re: [fpc-devel] Evaluation order in expressions

On 30.07.2019 09:46, Michael Van Canneyt wrote: I think they updated the documentation meanwhile: http://docwiki.embarcadero.com/RADStudio/Rio/en/Procedures_and_Functions_(Delphi)#Calling_Conventions So you can see it depends on the calling convention. Thanks, I wasn't aware of it!

Re: [fpc-devel] Evaluation order in expressions

On 30.07.2019 08:55, Jonas Maebe wrote: Delphi evaluates e.g. all parameters to subroutine calls from left to right, which FPC does not guarantee. If I am not mistaken Delphi doesn't guarantee this either. I remember I "learned it by doing" quite some time ago and I don't think I used FPC at

Re: [fpc-devel] Evaluation order in expressions

On 30.07.2019 08:33, Michael Van Canneyt wrote: The documentation has already been fixed in this regard, there was a bugreport about it not so long ago. Great, thank you. Is there some online version of the latest documentation trunk (nightly build)? Ondrej

Re: [fpc-devel] Evaluation order in expressions

On 30.07.2019 08:23, Ondrej Pokorny wrote: /Remark: The order in which expressions of the same precedence are evaluated is not guaranteed to be left-to-right./ Is this valid for boolean expressions, too? I use the following construct with {$BOOLEVAL OFF}: Result := Assigned(MyObject

[fpc-devel] Evaluation order in expressions

Hello, can somebody comment on the Remark from https://www.freepascal.org/docs-html/ref/refch12.html ? /Remark: The order in which expressions of the same precedence are evaluated is not guaranteed to be left-to-right./ Is this valid for boolean expressions, too? I use the following

Re: [fpc-devel] Cannot build fpc trunk on MacOS

On 28.07.2019 13:15, Jonas Maebe wrote: On 28/07/2019 10:41, Ondrej Pokorny wrote: I wanted to try the latest FPC/Lazarus on Mac OS and I got the following error when building trunk with FPC 3.0.4: Sorry, fixed. I can build FPC trunk on MacOS now, thank you! Ondrej

[fpc-devel] Cannot build fpc trunk on MacOS

Hello, I wanted to try the latest FPC/Lazarus on Mac OS and I got the following error when building trunk with FPC 3.0.4: Installing package chm Installation package chm for target x86_64-darwin succeeded Start compiling package cocoaint for target x86_64-darwin.    Compiling

Re: [fpc-devel] Internal error 200510032 on SynEdit package

On 23.07.2019 16:05, denisgolovan wrote: Anybody knows whats going on and why it stopped working? (I am on Windows and use the 32bit compiler. Today's FPC trunk, today's Lazarus trunk.) Same story. See https://bugs.freepascal.org/view.php?id=35877 Thanks! Ondrej

[fpc-devel] Internal error 200510032 on SynEdit package

Hello, I updated trunk now and wanted to test the attributes support - and now I get Internal error 200510032 when compiling the SynEdit package. (See attached screenshot.) synedithighlighterxmlbase.pas(236,31) Error: Internal error 200510032 Rebuild clean doesn't help. I can go over the

Re: [fpc-devel] Property attributes support

On 20.07.2019 13:56, Sven Barth via fpc-devel wrote: Here: https://wiki.freepascal.org/Custom_Attributes Thank you! The old Wiki page should propably be updated to reflect the current state of affairs... I deleted the old information (nearly everything) and put a link to the new Wiki

[fpc-devel] Property attributes support

Hello! I saw that Sven committed property attributes support in trunk. Thank you for this! Is there any documentation how to use them? (Syntax, reading information during runtime etc?) I only found very old information: https://wiki.freepascal.org/Property_attributes

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 13.07.2019 13:47, J. Gareth Moreton wrote: Here lies the problem - if you have a enumeration stored in a byte field, say, in a file, and there's a chance it's been corrupted, there's no reliable way to detect that, since even typecasting may not be reliable, and once again I'm implying that

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 13.07.2019 14:32, Michael Van Canneyt wrote: I yesterday checked a database project I have. I counted 25 enumerateds which are stored in the database. Without fail, for each type there is somewhere code in a type helper: if (MyDatabaseValue>=0) and (MyDatabaseValue<=Ord(High(TMyENum)))

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 11.07.2019 11:58, J. Gareth Moreton wrote: Done! Thank you for your work! BTW, your note in the issue report is very misleading: https://bugs.freepascal.org/view.php?id=33603#c117162. > The idea behind "is" and "as" is that they are the sole exception to the rule and will return False

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 08.07.2019 17:19, J. Gareth Moreton wrote: I disabled it after Pierre pointed out that you couldn't use Pred or Succ with them, so wanted to be consistent, especially as programming them to return the expected value of False of a value falls within a hole is not simple. Still, it's easy

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 08.07.2019 02:37, J. Gareth Moreton wrote: Uploaded the latest patch (AS-IS-enum-07.patch) over here and also a test project that evaluates the "is" operator between different ordinal types. I though I convinced you not to disable the

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 08.07.2019 12:39, Giuliano Colla wrote: Il 07/07/2019 07:33, J. Gareth Moreton ha scritto: In the meantime, I'm working on making "as" and "is" work with ordinal types as well as enumerations, although currently some headaches occur if the right-hand side is larger than the CPU word size

Re: [fpc-devel] [] property overloads

On 06.07.2019 22:12, Ryan Joseph wrote: On Jul 6, 2019, at 4:09 PM, Ondrej Pokorny wrote: On 06.07.2019 20:03, Ryan Joseph wrote: Yeah that’s correct. Here’s my bug report: https://bugs.freepascal.org/view.php?id=35809 Did you just create a duplicate bug report to the one I linked

Re: [fpc-devel] [] property overloads

On 06.07.2019 20:03, Ryan Joseph wrote: Yeah that’s correct. Here’s my bug report: https://bugs.freepascal.org/view.php?id=35809 Did you just create a duplicate bug report to the one I linked in this thread before ( https://lists.freepascal.org/pipermail/fpc-devel/2019-July/041350.html )

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 22:44, J. Gareth Moreton wrote: In the meantime, I've extended your AS/IS patch over here to create efficient code for x86 platforms, although currently it only does a range check and won't correctly handle enumerations with

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 06.07.2019 02:10, Martok wrote: In that case, unlike what was previously said in this thread, this should simply work: generic function TStreamHelper.ReadEnum(out aEnum: T): Boolean; begin if Read(aEnum, SizeOf(aEnum)) <> SizeOf(aEnum) then Exit(False) else begin Result :=

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 16:51, Pierre Muller wrote: This means that using pred() or succ() intrinsics on enumerated types with holes will generate a Compile Time Error. To be consistent, I would propose that we also generate a Compile Time Error if 'is' or 'as' keyword is used on such a type, unless

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 16:51, Pierre Muller wrote: Just one point from current compiler implementation: in trunk/fpcsrc/compiler/ninl.pas (around line 3180) in_pred_x, in_succ_x: begin set_varstate(left,vs_read,[vsf_must_be_valid]);

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 14:58, Martok wrote: Am 05.07.2019 um 12:20 schrieb Ondrej Pokorny: Anything that even looks like a subrange cannot be used for these interfaces. You may use enumerations for these interfaces - you may just not fill them directly but through an integer variable in between when

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 14:58, Martok wrote: Am 05.07.2019 um 12:20 schrieb Ondrej Pokorny: Anything that even looks like a subrange cannot be used for these interfaces. You may use enumerations for these interfaces - you may just not fill them directly but through an integer variable in between when

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 11:08, Martok wrote: Am 05.07.2019 um 02:52 schrieb Michael Van Canneyt: With this sentence you forbid storing or communicating enumerated values in any way: file, database, over network. It can be used only in a computer program and never leave the context of the running

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 11:33, Michael Van Canneyt wrote: On Fri, 5 Jul 2019, Ondrej Pokorny wrote: On 05.07.2019 10:52, Sven Barth via fpc-devel wrote: Michael Van Canneyt <mailto:mich...@freepascal.org>> schrieb am Fr., 5. Juli 2019, 10:47:     If memory serves well, FPC introduced thi

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 10:52, Sven Barth via fpc-devel wrote: Michael Van Canneyt > schrieb am Fr., 5. Juli 2019, 10:47: If memory serves well, FPC introduced this (before delphi) to be able to import C enums with assigned values. Correct. That is also why we

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 09:57, Michael Van Canneyt wrote: On Fri, 5 Jul 2019, Ondrej Pokorny wrote: On 05.07.2019 09:04, Michael Van Canneyt wrote: In this, I would definitely exclude enumerateds that have explicitly assigned values: str does not handle them, getenumename etc. also do not work

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 05.07.2019 09:04, Michael Van Canneyt wrote: In this, I would definitely exclude enumerateds that have explicitly assigned values: str does not handle them, getenumename etc. also do not work: They are in effect simply integer constants. (if I had my way I would even remove them from the

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 04.07.2019 21:20, Jonas Maebe wrote: On 03/07/2019 09:26, Ondrej Pokorny wrote: On 02.07.2019 23:34, Jonas Maebe wrote: Invalid data means undefined behaviour, always. "is" is not a special case that is immune to this. Don't you really see the need to handle invalid data with

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 03.07.2019 02:37, J. Gareth Moreton wrote: On 03/07/2019 01:13, Ondrej Pokorny wrote: On 02.07.2019 23:34, Jonas Maebe wrote: As to your patch itself: why do you not directly compare the tconstexprint values directly, and use the svalue/uvalue fields instead? Because I missed

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 02.07.2019 23:34, Jonas Maebe wrote: Invalid data means undefined behaviour, always. "is" is not a special case that is immune to this. Don't you really see the need to handle invalid data with a /defined/ behavior? Enum and subrange types /can/ store invalid data and they /do/ store

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

On 03.07.2019 08:58, Ondrej Pokorny wrote: BTW I was always convinced that an explicit typecast switches off range checking. And now I open the documentation https://www.freepascal.org/docs-html/prog/progsu65.html and I read this: (citation) /If, at run-time, an index or enumeration type

  1   2   3   4   >