Re: [fpc-pascal] Bug or feature ?
Am 27.07.2022 um 15:14 schrieb Ched via fpc-pascal: Hello All, I have a long code which include lines for writing stuffs into an assigned writable text-file F. WRITELN(F: 'Hello'); WRITELN(F, 'Hello'); The code can be compiled with 3.2.2 in i386/windows and i386/linux and runs both times at perfection. But... i'm wondering if the first line is really legal... Any advice ? Write(), WriteLn() and WriteStr() (and Str()) allow to adjust the way a numerical value is written by using additional parameters delimited by colons: VarToOutput:NumChars[:Decimals] (see https://www.freepascal.org/docs-html/current/rtl/system/write.html ). That it nevertheless compiles correctly and executes as "Writeln(F, 'Hello')" is due to a bug in the handling of the parameters. So, please report a bug with a complete example that should fail. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug or feature ?
Le 27.07.2022 à 17:41, DougC via fpc-pascal a écrit : WRITELN(F: 'Hello'); is not proper Pascal. Yes, Doug, I agree ; but it is compiled with no warning and runs perfectly. Now, why the compiler do not complain... ? Cheers, Ched' ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug or feature ?
WRITELN(F: 'Hello'); is not proper Pascal.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Bug or feature ?
Hello All, I have a long code which include lines for writing stuffs into an assigned writable text-file F. WRITELN(F: 'Hello'); WRITELN(F, 'Hello'); The code can be compiled with 3.2.2 in i386/windows and i386/linux and runs both times at perfection. But... i'm wondering if the first line is really legal... Any advice ? Cheers, Ched'. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
This can't be right, can it? type TBird = class procedure Fly; end; TEagle = TBird; // alias procedure TEagle.Fly; begin end; It does depend on what you expect an Type-Alias to be. If you expect the compiler to generate an compatible class then your example must not be compilable. If you expect an alias die make the Typenames "TEagle" and "TBird" equivalent it is no problem for the compiler which name you use at what place. In any case I would judge such code as "bad style" - programmers should avoid doing so. Elmar ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
On Sun, 13 Feb 2022, Sven Barth via fpc-pascal wrote: Personally, I would not allow this. But Delphi compiles and runs it... ... and Delphi's class completion no longer works in the unit giving a useless error "expected ';' but '.' found". So it is one of those Delphi "features" compiling but not usable. I'm all for forbidding this in objfpc mode. Then file a bug report for it. Cause it's definitely going to be one of the low priority things cause it's going to be annoying to fix... Done: https://gitlab.com/freepascal.org/fpc/source/-/issues/39576 Maybe someone can check whether Florian's solution really is 'famous last words' ;-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
Am 13.02.2022 um 10:25 schrieb Sven Barth via fpc-pascal: Michael Van Canneyt via fpc-pascal mailto:fpc-pascal@lists.freepascal.org>> schrieb am So., 13. Feb. 2022, 09:47: On Sun, 13 Feb 2022, Mattias Gaertner via fpc-pascal wrote: > On Sat, 12 Feb 2022 12:14:14 +0100 (CET) > Michael Van Canneyt via fpc-pascal mailto:fpc-pascal@lists.freepascal.org>> > wrote: > >> On Sat, 12 Feb 2022, Mattias Gaertner via fpc-pascal wrote: >> >> > Hi, >> > >> > This can't be right, can it? >> > >> > type >> > TBird = class >> > procedure Fly; >> > end; >> > TEagle = TBird; // alias >> > >> > procedure TEagle.Fly; >> > begin >> > end; >> >> Personally, I would not allow this. >> But Delphi compiles and runs it... > > ... and Delphi's class completion no longer works in the unit giving a > useless error "expected ';' but '.' found". So it is one of those > Delphi "features" compiling but not usable. I'm all for forbidding this in objfpc mode. Then file a bug report for it. Cause it's definitely going to be one of the low priority things cause it's going to be annoying to fix... I thought (famous last words), checking the typesyms of the tobjectdef would be enough but who knows what else will bit :) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
Michael Van Canneyt via fpc-pascal schrieb am So., 13. Feb. 2022, 09:47: > > > On Sun, 13 Feb 2022, Mattias Gaertner via fpc-pascal wrote: > > > On Sat, 12 Feb 2022 12:14:14 +0100 (CET) > > Michael Van Canneyt via fpc-pascal > > wrote: > > > >> On Sat, 12 Feb 2022, Mattias Gaertner via fpc-pascal wrote: > >> > >> > Hi, > >> > > >> > This can't be right, can it? > >> > > >> > type > >> > TBird = class > >> >procedure Fly; > >> > end; > >> > TEagle = TBird; // alias > >> > > >> > procedure TEagle.Fly; > >> > begin > >> > end; > >> > >> Personally, I would not allow this. > >> But Delphi compiles and runs it... > > > > ... and Delphi's class completion no longer works in the unit giving a > > useless error "expected ';' but '.' found". So it is one of those > > Delphi "features" compiling but not usable. > > I'm all for forbidding this in objfpc mode. > Then file a bug report for it. Cause it's definitely going to be one of the low priority things cause it's going to be annoying to fix... Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
On Sun, 13 Feb 2022, Mattias Gaertner via fpc-pascal wrote: On Sat, 12 Feb 2022 12:14:14 +0100 (CET) Michael Van Canneyt via fpc-pascal wrote: On Sat, 12 Feb 2022, Mattias Gaertner via fpc-pascal wrote: > Hi, > > This can't be right, can it? > > type > TBird = class >procedure Fly; > end; > TEagle = TBird; // alias > > procedure TEagle.Fly; > begin > end; Personally, I would not allow this. But Delphi compiles and runs it... ... and Delphi's class completion no longer works in the unit giving a useless error "expected ';' but '.' found". So it is one of those Delphi "features" compiling but not usable. I'm all for forbidding this in objfpc mode. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
On Sat, 12 Feb 2022 12:14:14 +0100 (CET) Michael Van Canneyt via fpc-pascal wrote: > On Sat, 12 Feb 2022, Mattias Gaertner via fpc-pascal wrote: > > > Hi, > > > > This can't be right, can it? > > > > type > > TBird = class > >procedure Fly; > > end; > > TEagle = TBird; // alias > > > > procedure TEagle.Fly; > > begin > > end; > > Personally, I would not allow this. > But Delphi compiles and runs it... ... and Delphi's class completion no longer works in the unit giving a useless error "expected ';' but '.' found". So it is one of those Delphi "features" compiling but not usable. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
On Sun, 13 Feb 2022, Ryan Joseph via fpc-pascal wrote: On Feb 12, 2022, at 11:40 PM, Jonas Maebe via fpc-pascal wrote: I wouldn't consider this to be working by design, but rather because of implementation limitations. I agree and it should be fixed probably. As I wrote in my initial answer to Mattias, I would also forbid it. (despite the temptation to use it for shortening class names in the implementation, I think it will be more confusing than helpful in the end) But since Delphi allows it, we must continue to allow it in Delphi mode... Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
> On Feb 12, 2022, at 11:40 PM, Jonas Maebe via fpc-pascal > wrote: > > I wouldn't consider this to be working by design, but rather because of > implementation limitations. I agree and it should be fixed probably. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
On Sat, 12 Feb 2022 17:58:27 +0100 Jonas Maebe via fpc-pascal wrote: >[...] > >> I wouldn't consider this to be working by design, but rather > >> because of implementation limitations. +1 pas2js complained. That's how I found out. Someone renamed a class, added an alias for compatibility, forgot to rename the implementation, and fpc did not complain. > > Why do you consider it a limitation ? > > > > Because the compiler currently has no way to distinguish the types > > when resolving the > > name "T" (as used in my example)? > > Indeed. > > > Then it is a strange coincidence that Delphi has it too :-) > > The simplest way to implement alias types is to just have them refer > to the original type... Actually pas2js did an even simpler approach here: Look up the identifier without resolving the original type ;) Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
On 12/02/2022 17:47, Michael Van Canneyt via fpc-pascal wrote: On Sat, 12 Feb 2022, Jonas Maebe via fpc-pascal wrote: On 12/02/2022 17:36, Michael Van Canneyt via fpc-pascal wrote: PS. Just tested, the compiler accepts both... Amazing, I never thought this would be possible. I'd better update the docs :-) I wouldn't consider this to be working by design, but rather because of implementation limitations. Why do you consider it a limitation ? Because the compiler currently has no way to distinguish the types when resolving the name "T" (as used in my example)? Indeed. Then it is a strange coincidence that Delphi has it too :-) The simplest way to implement alias types is to just have them refer to the original type... Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
On Sat, 12 Feb 2022, Jonas Maebe via fpc-pascal wrote: On 12/02/2022 17:36, Michael Van Canneyt via fpc-pascal wrote: PS. Just tested, the compiler accepts both... Amazing, I never thought this would be possible. I'd better update the docs :-) I wouldn't consider this to be working by design, but rather because of implementation limitations. Why do you consider it a limitation ? Because the compiler currently has no way to distinguish the types when resolving the name "T" (as used in my example)? Then it is a strange coincidence that Delphi has it too :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
On 12/02/2022 17:36, Michael Van Canneyt via fpc-pascal wrote: PS. Just tested, the compiler accepts both... Amazing, I never thought this would be possible. I'd better update the docs :-) I wouldn't consider this to be working by design, but rather because of implementation limitations. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
On Sat, 12 Feb 2022, Sven Barth via fpc-pascal wrote: Michael Van Canneyt via fpc-pascal schrieb am Sa., 12. Feb. 2022, 12:14: On Sat, 12 Feb 2022, Mattias Gaertner via fpc-pascal wrote: Hi, This can't be right, can it? type TBird = class procedure Fly; end; TEagle = TBird; // alias procedure TEagle.Fly; begin end; Personally, I would not allow this. But Delphi compiles and runs it... Maybe something to check for {$mode objfpc} =-) The compiler does not have any real tracking for non-type aliases... As far as the compiler is concerned these are interchangeable... I think Mattias just got some more gray hairs :-) So if I understand this correctly, I can do --- Interface Type TSomeReallyAnnoyingIncrediblyLongClassName = Class Procedure DoSomething; end; implementation Type T1 = TSomeReallyAnnoyingUltraLongClassName; procedure T1.DoSomething; begin end; --- And consequently also --- Interface Type TSomeReallyAnnoyingIncrediblyLongClassName = Class Type TSomeReallyAnnoyingSubClass = class Procedure DoSomething; end; end; implementation Type T1 = TSomeReallyAnnoyingIncrediblyLongClassName.TSomeReallyAnnoyingSubClass; procedure T1.DoSomething; begin end; --- The lazarus code tools maintainer will have a field day with this one ;-) Michael. PS. Just tested, the compiler accepts both... Amazing, I never thought this would be possible. I'd better update the docs :-) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
Michael Van Canneyt via fpc-pascal schrieb am Sa., 12. Feb. 2022, 12:14: > > > On Sat, 12 Feb 2022, Mattias Gaertner via fpc-pascal wrote: > > > Hi, > > > > This can't be right, can it? > > > > type > > TBird = class > >procedure Fly; > > end; > > TEagle = TBird; // alias > > > > procedure TEagle.Fly; > > begin > > end; > > Personally, I would not allow this. > But Delphi compiles and runs it... > > Maybe something to check for {$mode objfpc} =-) > The compiler does not have any real tracking for non-type aliases... As far as the compiler is concerned these are interchangeable... Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature?
On Sat, 12 Feb 2022, Mattias Gaertner via fpc-pascal wrote: Hi, This can't be right, can it? type TBird = class procedure Fly; end; TEagle = TBird; // alias procedure TEagle.Fly; begin end; Personally, I would not allow this. But Delphi compiles and runs it... Maybe something to check for {$mode objfpc} =-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] bug or feature?
Hi, This can't be right, can it? type TBird = class procedure Fly; end; TEagle = TBird; // alias procedure TEagle.Fly; begin end; Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature
Am 01.01.2021 um 19:21 schrieb Mattias Gaertner via fpc-pascal: Hi, library test; procedure Test; begin end; exports Test name 3 'abc'; //^^^ end. It's a bug. Please report. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug or feature
On Fri, 1 Jan 2021, Mattias Gaertner via fpc-pascal wrote: Hi, library test; procedure Test; begin end; exports Test name 3 'abc'; //^^^ end. I think this is a bug. Delphi also barfs on it. However the following does work: exports Test index 1 name 'abc'; Although incomplete, the following does not mention you can include a number: http://docwiki.embarcadero.com/RADStudio/Sydney/en/Writing_Dynamically_Loaded_Libraries Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] bug or feature
Hi, library test; procedure Test; begin end; exports Test name 3 'abc'; //^^^ end. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug tracker (bugs.freepascal.org) APPLICATION ERROR #400 (db connection failed)
On Sun, Aug 30, 2020 at 11:26 AM Michael Van Canneyt via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > > > On Sun, 30 Aug 2020, Christo Crause via fpc-pascal wrote: > > > On Sun, Aug 30, 2020 at 9:45 AM Dmitry Boyarintsev via fpc-pascal < > > fpc-pascal@lists.freepascal.org> wrote: > > > >> The site opens up with: > >> > >> APPLICATION ERROR #400 > >> > > > > I also get the above mentioned error when trying to open the website. > > The problem should be fixed. > I confirm the bug tracker is available again. Thank you Michael! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug tracker (bugs.freepascal.org) APPLICATION ERROR #400 (db connection failed)
On Sun, 30 Aug 2020, Christo Crause via fpc-pascal wrote: On Sun, Aug 30, 2020 at 9:45 AM Dmitry Boyarintsev via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: The site opens up with: APPLICATION ERROR #400 I also get the above mentioned error when trying to open the website. The problem should be fixed. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug tracker (bugs.freepascal.org) APPLICATION ERROR #400 (db connection failed)
On Sun, Aug 30, 2020 at 9:45 AM Dmitry Boyarintsev via fpc-pascal < fpc-pascal@lists.freepascal.org> wrote: > The site opens up with: > > APPLICATION ERROR #400 > I also get the above mentioned error when trying to open the website. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] bug tracker (bugs.freepascal.org) APPLICATION ERROR #400 (db connection failed)
The site opens up with: APPLICATION ERROR #400 Database connection failed. Error received from database was #-1: Database connection failed. Please use the "Back" button in your web browser to return to the previous page. There you can correct whatever problems were identified in this error or select another action. You can also click an option from the menu bar to go directly to a new section. thanks, Dmitry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
Op 15-05-2020 om 12:48 schreef Michael Van Canneyt: On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote: As a consequence, StrToHostAddr will happily parse addresses like these: 0xa.3.4.5 9.$c.4.5 %.%11001110.30.4 &7.&5.30.4 12.+4.1.1 Fixed. Ahh.. why.. An ip-address of 0xa.&5.%11001110.3 is just funny. Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On Sun, 17 May 2020, Noel Duffy via fpc-pascal wrote: On 17/05/20 3:00 am, Michael Van Canneyt wrote: On Sat, 16 May 2020, Michael Van Canneyt wrote: On Sat, 16 May 2020, Jonas Maebe wrote: On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote: While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. I added a note to https://bugs.freepascal.org/view.php?id=37013 about the fact that this test program fails if range checking is enabled (I don't know if the range error is in StrToHostAddr6 or in the test program itself). I will check. I never use range checking, so that could have easily escaped me. Fixed 2 occurrences of a range check. Looking at the code in SVN, I spotted a couple of still extant references to s6_addr16 instead of u6_addr16 in StrToHostAddr6. It's possible to trigger range check errors for them. All s6_addr16s should be u6_addr16s. If you try parsing an address like '::' it will hit this part of the code. Sorry for the screw-up. Normally I religiously use range checks in my own code, but it completely went out of my head when working on this. That's what you get when communication with someone who doesn't use them: It's contagious ;-) I'll have a look. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On 17/05/20 3:00 am, Michael Van Canneyt wrote: On Sat, 16 May 2020, Michael Van Canneyt wrote: On Sat, 16 May 2020, Jonas Maebe wrote: On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote: While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. I added a note to https://bugs.freepascal.org/view.php?id=37013 about the fact that this test program fails if range checking is enabled (I don't know if the range error is in StrToHostAddr6 or in the test program itself). I will check. I never use range checking, so that could have easily escaped me. Fixed 2 occurrences of a range check. Looking at the code in SVN, I spotted a couple of still extant references to s6_addr16 instead of u6_addr16 in StrToHostAddr6. It's possible to trigger range check errors for them. All s6_addr16s should be u6_addr16s. If you try parsing an address like '::' it will hit this part of the code. Sorry for the screw-up. Normally I religiously use range checks in my own code, but it completely went out of my head when working on this. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On 17/05/20 1:21 am, Jonas Maebe wrote: On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote: While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. I added a note to https://bugs.freepascal.org/view.php?id=37013 about the fact that this test program fails if range checking is enabled (I don't know if the range error is in StrToHostAddr6 or in the test program itself). D'oh! Normally I'm scrupulous about turning on range checks in my own programs, but I completely forgot to do that here. But I see Michael has already fixed it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On Sat, 16 May 2020, Michael Van Canneyt wrote: On Sat, 16 May 2020, Jonas Maebe wrote: On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote: While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. I added a note to https://bugs.freepascal.org/view.php?id=37013 about the fact that this test program fails if range checking is enabled (I don't know if the range error is in StrToHostAddr6 or in the test program itself). I will check. I never use range checking, so that could have easily escaped me. Fixed 2 occurrences of a range check. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On Sat, 16 May 2020, Jonas Maebe wrote: On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote: While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. I added a note to https://bugs.freepascal.org/view.php?id=37013 about the fact that this test program fails if range checking is enabled (I don't know if the range error is in StrToHostAddr6 or in the test program itself). I will check. I never use range checking, so that could have easily escaped me. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On 15/05/2020 12:39, Noel Duffy via fpc-pascal wrote: > While doing some work on bug 37060, the refactoring of StrToHostAddr and > StrToHostAddr6 in the sockets > unit,(https://bugs.freepascal.org/view.php?id=37060), I found that > StrToHostAddr is doing no validation at all on input address characters > before calling the function Val, so any Pascal notation that Val > accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, > and mathematical signs are all accepted in ipv4 octets. I added a note to https://bugs.freepascal.org/view.php?id=37013 about the fact that this test program fails if range checking is enabled (I don't know if the range error is in StrToHostAddr6 or in the test program itself). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On 15/05/20 11:25 pm, Michael Van Canneyt wrote: On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote: That must be a new record in bug fix speed. You fixed that within ten minutes of my message to the list! I forgot to mention in my message, but did mention in the bug report, that leading zeroes are also allowed, so you can parse: 01.1.1.1 Personally I don't think this is a problem (mathematically, you can add as many zeroes as you like), but I can imagine some do, so I fixed it. Well, the same argument could be made for allowing hexadecimal or other notations. But ip address representation formats aren't just numbers, they're textual representations meant for easy transmission between programs and across networks, and the standards documents are quite clear about what's allowed in them and what's not. If StrToHostAddr breaks with those standards and accepts addresses that other implementations won't, or rejects addresses others accept, that makes it unusable for programs that must operate in mixed language environments. In my own case, I'm writing a program to parse and validate SPF records, as defined in RFC7208. SPF records are read and processed by SMTP servers as they receive mail, so any tools that attempt to validate SPF records must not accept as valid any ipv4 or ipv6 address that the SMTP server won't also accept. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote: That must be a new record in bug fix speed. You fixed that within ten minutes of my message to the list! I forgot to mention in my message, but did mention in the bug report, that leading zeroes are also allowed, so you can parse: 01.1.1.1 Personally I don't think this is a problem (mathematically, you can add as many zeroes as you like), but I can imagine some do, so I fixed it. Rev. 45368. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On 15/05/20 10:48 pm, Michael Van Canneyt wrote: On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote: While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. https://bugs.freepascal.org/view.php?id=37080 As a consequence, StrToHostAddr will happily parse addresses like these: 0xa.3.4.5 9.$c.4.5 %.%11001110.30.4 &7.&5.30.4 12.+4.1.1 Any number in any notation will be accepted as long as byte overflow isn't triggered. Thus, + in octets is accepted, but - is not, because the function detects that the octet is negative which then triggers overflow. Fixing this is outside the scope of the patch I'm preparing for 37060, but if no-one else feels inclined to look into this by the time I'm finished with that patch then I'll submit a new patch for it. Fixed. That must be a new record in bug fix speed. You fixed that within ten minutes of my message to the list! I forgot to mention in my message, but did mention in the bug report, that leading zeroes are also allowed, so you can parse: 01.1.1.1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
On Fri, 15 May 2020, Noel Duffy via fpc-pascal wrote: While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. https://bugs.freepascal.org/view.php?id=37080 As a consequence, StrToHostAddr will happily parse addresses like these: 0xa.3.4.5 9.$c.4.5 %.%11001110.30.4 &7.&5.30.4 12.+4.1.1 Any number in any notation will be accepted as long as byte overflow isn't triggered. Thus, + in octets is accepted, but - is not, because the function detects that the octet is negative which then triggers overflow. Fixing this is outside the scope of the patch I'm preparing for 37060, but if no-one else feels inclined to look into this by the time I'm finished with that patch then I'll submit a new patch for it. Fixed. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Bug 37080 -- StrToHostAddr accepts all Pascal number notations
While doing some work on bug 37060, the refactoring of StrToHostAddr and StrToHostAddr6 in the sockets unit,(https://bugs.freepascal.org/view.php?id=37060), I found that StrToHostAddr is doing no validation at all on input address characters before calling the function Val, so any Pascal notation that Val accepts, such as 0x and $ for hexadecimal, % for binary, & for octal, and mathematical signs are all accepted in ipv4 octets. https://bugs.freepascal.org/view.php?id=37080 As a consequence, StrToHostAddr will happily parse addresses like these: 0xa.3.4.5 9.$c.4.5 %.%11001110.30.4 &7.&5.30.4 12.+4.1.1 Any number in any notation will be accepted as long as byte overflow isn't triggered. Thus, + in octets is accepted, but - is not, because the function detects that the octet is negative which then triggers overflow. Fixing this is outside the scope of the patch I'm preparing for 37060, but if no-one else feels inclined to look into this by the time I'm finished with that patch then I'll submit a new patch for it. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] bug while generating androidR25.pas and Androidr25.inc
I know, that this task is heavy and should be only performed by The elites among Pascal programmers not by users of this programming language. But I Am sure, that if somebody experienced will answer. on my question, it would increase The number of volunteers, who would be ready to generate newer and newer Android header files, because Android APIS versions are newer and newer. I Am getting The bug related to swing. Here is whole part of window. C:\pasandr>java -jar javapp.jar -bootclasspath C:\Program Files (x86)\Android\android-sdk\platforms\android-25\android.jar -extdirs . -protected -x java.lang.System -x java.lang.Object -x java.io.Serializable -x java.io.IOException -x java.io.IIOException -x java.lang.Readable -x java.lang.Float -x java.lang.Double -x java.lang.Float -x java.lang.Double -x java.lang.Byte -x java.lang.Short -x java.lang.Integer -x java.lang.Long -x java.lang.Boolean -x java.lang.String -x java.lang.StringBuilder -x java.lang.StringBuffer -x java.lang.CharSequence -x java.lang.AbstractStringBuilder -x java.lang.Appendable -x java.lang.Number -x java.lang.IndexOutOfBoundsException -x java.lang.RuntimeException -x java.lang.IllegalArgumentException -x java.lang.IllegalStateException -x java.lang.UnsupportedOperationException -x java.lang.Exception -x java.lang.Throwable -x java.lang.LinkageError -x java.lang.Error -x java.lang.Comparable -x java.lang.Character -x java.text.Collator -x java.lang.Cloneable -x java.lang.Runtime -x java.lang.ThreadLocal -x java.math.BigInteger -x java.util.Comparator -x java.lang.reflect.Array -x java.lang.Class -x java.lang.reflect.GenericDeclaration -x java.lang.reflect.Type -x java.lang.reflect.Method -x java.lang.reflect.AccessibleObject -x java.lang.reflect.Member -x java.lang.reflect.AnnotatedElement -x java.lang.reflect.Field -x java.lang.reflect.InvocationTargetException -x java.util.Arrays -x java.util.Map -x java.util.HashMap -x java.util.Set -x java.util.Collection -x java.util.AbstractMap -x java.util.Calendar -x java.lang.Iterable -x java.lang.Enum -x java.lang.Math -x java.util.AbstractCollection -x java.util.AbstractSet -x java.util.EnumSet -x java.util.BitSet -x java.util.Iterator -x java.nio.Buffer -x java.nio.ByteBuffer -x java.nio.CharBuffer -x java.nio.charset. -a sun. -a com.sun. -a apple. -a java.awt. java. javax. org. android. junit. -o androidrNo default charset: windows-1250 Determining short Pascal class names... Indexing classes under (x86)\Android\android-sdk\platforms\android-25\android/jar... Indexing classes under Files... Indexing classes under android/... Indexing classes under java/... Indexing classes under javax/... Indexing classes under junit/... Indexing classes under org/... ERROR:Could not find javax/swing/JApplet C:\pasandr> I AM running jdk1.7.0_79 And The same version of JRE X86 with Windows 10 Home Edition 64 BIt. Sure! I know, that even when I generate .pas and .inc files, I will not get ready header files. There is plenty of work to make because of classes naming. If somebody will know The answer, it would be really useful. Thank you very very much. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On Tue, Mar 26, 2019 at 11:18 AM Cyrax wrote: > > I added poNoConsole to the 2 occasions of TProcessUtf8 I could fine in > > InitialSetupDlg, but I still see 2 console windows flashing by. > Does adding clauses for TProcess.StartupOptions := [suoUseShowWindow] > and TProcess.ShowWindow := swoHIDE help? Makes no difference at all. I totally removed all that code from InitialSetUpDlg and I still see 2 console windows flashing. So something else in the IDE seems to do that. -- Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On 24.3.2019 19.36, Bart wrote: On Sun, Mar 24, 2019 at 6:10 PM Joost van der Sluis wrote: Note: I see several times a window (console?) flash when starting up Lazarus now. Maybe add poNoConsole to ProcessOptions ? It's a bit annoying now. Can you test if this actually works on Windows (on Linux this is not an issue) I added poNoConsole to the 2 occasions of TProcessUtf8 I could fine in InitialSetupDlg, but I still see 2 console windows flashing by. Adding [poNoconsole] may also prevent the program in question to write output to StdOut? But since we're using pipes, that should not matter? Sorry, I just never use that stuff in my programs. Bart Does adding clauses for TProcess.StartupOptions := [suoUseShowWindow] and TProcess.ShowWindow := swoHIDE help? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On Sun, Mar 24, 2019 at 11:41 PM Bart wrote: > > Sorry, I just never use that stuff in my programs. In a simple test program I can make this work withou a console wndow popping up: procedure TForm1.Button1Click(Sender: TObject); var S: String; begin Proc.Executable := 'C:\pp\bin\i386-win32\fpcmkcfg.exe'; Proc.Options := [poWaitOnExit,poUsePipes]; if paramstr(1)='no' then Proc.Options := [poWaitOnExit,poNoConsole,poUsePipes]; Proc.Parameters.Add('-V'); Proc.Execute; SetLength(S, Proc.Output.NumBytesAvailable); wr('Proc.Output.NumBytesAvailable='+IntToSTr(Proc.Output.NumBytesAvailable)); if Proc.Output.NumBytesAvailable>0 then Proc.Output.Read(S[1], Proc.Output.NumBytesAvailable) else S:='No sigar...'; wr(format('S= "%s"',[S])); wr('Proc.ExitCode='+Proc.ExitCode.ToHexString+ ', Proc.ExitStatus='+ Proc.ExitStatus.ToHexString); Proc.Free; end; So, now I'm not sure why I see 2 console windows popping in and out of existence when starting IDE... -- Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On Sun, Mar 24, 2019 at 6:36 PM Bart wrote: > Sorry, I just never use that stuff in my programs. It seems that when you try to execute a program that writes to console and you specify [poNoconsole] then the program will exit with: Proc.ExitCode=C005, Proc.ExitStatus=C005 -- Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On Sun, Mar 24, 2019 at 6:10 PM Joost van der Sluis wrote: > > Note: I see several times a window (console?) flash when starting up > > Lazarus now. > > Maybe add poNoConsole to ProcessOptions ? > > It's a bit annoying now. > > Can you test if this actually works on Windows (on Linux this is not an > issue) I added poNoConsole to the 2 occasions of TProcessUtf8 I could fine in InitialSetupDlg, but I still see 2 console windows flashing by. Adding [poNoconsole] may also prevent the program in question to write output to StdOut? But since we're using pipes, that should not matter? Sorry, I just never use that stuff in my programs. Bart -- Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
Op 24-03-19 om 11:48 schreef Bart: On Sun, Mar 24, 2019 at 1:30 AM Bart wrote: Now I get the rather ludicrous error message: "Warning: The fpcmkcfg configuration tool it too old [3.3.1]." In function TInitialSetupDialog.CheckFpcmkcfgQuality(out Note: string): TSDFilenameQuality; else if not ((Ver.Major = 0) or (Ver.Major > 3) or (((Ver.Major = 3)) and (Ver.Minor>3))) then <<= begin // fpcmkcfg's version must be > 3.1. I think the above code checks for 0.x, 4.x and > 3.3.x, which is not what the comment says. Sorry. I had to test the message, so adapted the check so that it needs at least 3.4.0. And accidentally comitted that. I changed that to else if not ((Ver.Major = 0) or (Ver.Major > 3) or (((Ver.Major = 3)) and (Ver.Minor>1))) then Now it lets me create a new Fppkg configuration. Good to hear. Note: I see several times a window (console?) flash when starting up Lazarus now. Maybe add poNoConsole to ProcessOptions ? It's a bit annoying now. Can you test if this actually works on Windows (on Linux this is not an issue) Joost ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On Sun, Mar 24, 2019 at 1:30 AM Bart wrote: > fpcmkcfg.exe does not support -V parameter Never mind that: it helps if you actually rebuild fpc, not just update the sources ;-) fpcmkcfg -h however does not list the "-V" option. Now I get the rather ludicrous error message: "Warning: The fpcmkcfg configuration tool it too old [3.3.1]." In function TInitialSetupDialog.CheckFpcmkcfgQuality(out Note: string): TSDFilenameQuality; else if not ((Ver.Major = 0) or (Ver.Major > 3) or (((Ver.Major = 3)) and (Ver.Minor>3))) then <<= begin // fpcmkcfg's version must be > 3.1. I think the above code checks for 0.x, 4.x and > 3.3.x, which is not what the comment says. I changed that to else if not ((Ver.Major = 0) or (Ver.Major > 3) or (((Ver.Major = 3)) and (Ver.Minor>1))) then Now it lets me create a new Fppkg configuration. Note: I see several times a window (console?) flash when starting up Lazarus now. Maybe add poNoConsole to ProcessOptions ? It's a bit annoying now. -- Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
Op 24-03-19 om 01:33 schreef Bart: Notice also that when you cancel the InitialSetupDialog, the IDE raises an exception when closing down: LAZARUS END - cleaning up ... [FORMS.PP] ExceptionOccurred Sender=EAccessViolation Exception=Access violation Stack trace: $0056EB8A TWINCONTROL__HANDLEALLOCATED, line 7442 of ./include/wincontrol.inc $0045493A TMAINIDE__SETTOOLSTATUS, line 3611 of main.pp $0044CF1C TMAINIDE__DESTROY, line 1648 of main.pp $0040FDA2 TOBJECT__FREE, line 336 of C:/devel/fpc/trunk/rtl/inc/objpas.inc TApplication.HandleException: EAccessViolation Access violation Stack trace: $0056EB8A TWINCONTROL__HANDLEALLOCATED, line 7442 of ./include/wincontrol.inc $0045493A TMAINIDE__SETTOOLSTATUS, line 3611 of main.pp $0044CF1C TMAINIDE__DESTROY, line 1648 of main.pp $0040FDA2 TOBJECT__FREE, line 336 of C:/devel/fpc/trunk/rtl/inc/objpas.inc TApplication.HandleException: Strange Exception Exception at 0056EB8A: EAccessViolation: Access violation. Stack trace: $0056EB8A TWINCONTROL__HANDLEALLOCATED, line 7442 of ./include/wincontrol.inc $0045493A TMAINIDE__SETTOOLSTATUS, line 3611 of main.pp $0044CF1C TMAINIDE__DESTROY, line 1648 of main.pp $0040FDA2 TOBJECT__FREE, line 336 of C:/devel/fpc/trunk/rtl/inc/objpas.inc Hint: (lazarus) [TMainIDE.Destroy] B -> inherited Destroy... TMainIDE Hint: (lazarus) [TMainIDE.Destroy] END I noticed this also, tried to fix it, but did not succeed so far. (I don't think it has anything to do with my changes, the problem was already there) Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
Op 24-03-19 om 01:30 schreef Bart: On Sat, Mar 23, 2019 at 7:56 PM Bart wrote: "Warning: Failed to retrieve the version of the fpcmkcfg configuration tool. It is probably too old to create the configuration files. Make sure a recent version is installed and available in the path or alongside the compiler-executable." Then later in TInitialSetupDialog.CheckFpcmkcfgQuality TInitialSetupDialog.CheckFpcmkcfgQuality A FpcmkcfgExecutable=C:\pp\bin\i386-win32\fpcmkcfg.exe FileExistsUtf8(FpcmkcfgExecutable)=True Proc.Options := proc.Options + [poWaitOnExit,poUsePipes]; // Write fppkg.cfg Proc.Executable := FpcmkcfgExecutable; proc.Parameters.Add('-V'); proc.Execute; Error: proc.ExitStatus=1 C:\pp\bin\i386-win32>fpcmkcfg -h Usage: fpcmkcfg.exe [options] Where options is one or more of -t filename Template file name. Default is built-in -o filename Set output file. Default is standard output. -d name=value define name=value pair. -hshow this help and exit. -u name remove name from list of name/value pairs. -mshow builtin macros and exit. -bshow builtin template and exit. -sskip the creation of a backup-file. -pforce directory creation. -vbe verbose. -0use built in fpc.cfg template (default) -1use built in fp.cfg template -2use built in fp.ini template -3use built in fppkg.cfg template -4use built in fppkg default compiler template fpcmkcfg.exe does not support -V parameter fppkg.exe does support -V parameter and shows: Warning: The directory "C:\Users\Bart\AppData\Local\FreePascal\fppkg\config/conf.d\" of the include-mask "C:\Users\Bart\AppData\Local\FreePascal\fppkg\config/conf.d/*.conf" does not exist Version: 3.3.1 The -V option has been added in r41742, but it has only been added to the help-screen in r41771. You have a version which is in between those two. So can you test 'fpcmkcfg -V'. Seems like this does not work, as in Lazarus it gives a problem. But given your fpc-revision, it should work? Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
Notice also that when you cancel the InitialSetupDialog, the IDE raises an exception when closing down: LAZARUS END - cleaning up ... [FORMS.PP] ExceptionOccurred Sender=EAccessViolation Exception=Access violation Stack trace: $0056EB8A TWINCONTROL__HANDLEALLOCATED, line 7442 of ./include/wincontrol.inc $0045493A TMAINIDE__SETTOOLSTATUS, line 3611 of main.pp $0044CF1C TMAINIDE__DESTROY, line 1648 of main.pp $0040FDA2 TOBJECT__FREE, line 336 of C:/devel/fpc/trunk/rtl/inc/objpas.inc TApplication.HandleException: EAccessViolation Access violation Stack trace: $0056EB8A TWINCONTROL__HANDLEALLOCATED, line 7442 of ./include/wincontrol.inc $0045493A TMAINIDE__SETTOOLSTATUS, line 3611 of main.pp $0044CF1C TMAINIDE__DESTROY, line 1648 of main.pp $0040FDA2 TOBJECT__FREE, line 336 of C:/devel/fpc/trunk/rtl/inc/objpas.inc TApplication.HandleException: Strange Exception Exception at 0056EB8A: EAccessViolation: Access violation. Stack trace: $0056EB8A TWINCONTROL__HANDLEALLOCATED, line 7442 of ./include/wincontrol.inc $0045493A TMAINIDE__SETTOOLSTATUS, line 3611 of main.pp $0044CF1C TMAINIDE__DESTROY, line 1648 of main.pp $0040FDA2 TOBJECT__FREE, line 336 of C:/devel/fpc/trunk/rtl/inc/objpas.inc Hint: (lazarus) [TMainIDE.Destroy] B -> inherited Destroy... TMainIDE Hint: (lazarus) [TMainIDE.Destroy] END -- Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On Sat, Mar 23, 2019 at 7:56 PM Bart wrote: > "Warning: Failed to retrieve the version of the fpcmkcfg configuration > tool. It is probably too old to create the configuration files. Make > sure a recent version is installed and available in the path or > alongside the compiler-executable." in TInitialSetupDialog.UpdateFppkgCandidates CheckPath('C:\PP', Result) calls CheckFppkgQuality, which for 'C:\PP' sets result to sddqCompatible (Minor error in the code: DirPathExistsCached(C:\PP\\fpmkinst)=True DirPathExistsCached(C:\PP\\units)=True Notice the double backslashes: we call DirPathExistsCached(LibPath+PathDelim+'fpmkinst') but 1 line above we already did: LibPath := IncludeTrailingPathDelimiter(LibPath); ) Then later in TInitialSetupDialog.CheckFpcmkcfgQuality TInitialSetupDialog.CheckFpcmkcfgQuality A FpcmkcfgExecutable=C:\pp\bin\i386-win32\fpcmkcfg.exe FileExistsUtf8(FpcmkcfgExecutable)=True Proc.Options := proc.Options + [poWaitOnExit,poUsePipes]; // Write fppkg.cfg Proc.Executable := FpcmkcfgExecutable; proc.Parameters.Add('-V'); proc.Execute; Error: proc.ExitStatus=1 C:\pp\bin\i386-win32>fpcmkcfg -h Usage: fpcmkcfg.exe [options] Where options is one or more of -t filename Template file name. Default is built-in -o filename Set output file. Default is standard output. -d name=value define name=value pair. -hshow this help and exit. -u name remove name from list of name/value pairs. -mshow builtin macros and exit. -bshow builtin template and exit. -sskip the creation of a backup-file. -pforce directory creation. -vbe verbose. -0use built in fpc.cfg template (default) -1use built in fp.cfg template -2use built in fp.ini template -3use built in fppkg.cfg template -4use built in fppkg default compiler template fpcmkcfg.exe does not support -V parameter fppkg.exe does support -V parameter and shows: Warning: The directory "C:\Users\Bart\AppData\Local\FreePascal\fppkg\config/conf.d\" of the include-mask "C:\Users\Bart\AppData\Local\FreePascal\fppkg\config/conf.d/*.conf" does not exist Version: 3.3.1 -- Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
I installed fpctrunk from sources r41749 (make clean; make install). It resides in C:\PP I think it is not an unusual setup. I built lazarus trunk r60747 with it. Lazarus tells me: "Warning: Failed to retrieve the version of the fpcmkcfg configuration tool. It is probably too old to create the configuration files. Make sure a recent version is installed and available in the path or alongside the compiler-executable." But it (fpcmkcfg ) is there, in the same folder as the compiler: C:\pp\bin\i386-win32>dir fpcmkcfg.exe /b fpcmkcfg.exe C:\pp\bin\i386-win32>dir ppc386.exe /b ppc386.exe C:\pp\bin\i386-win32>dir fpc.exe /b fpc.exe And it is the current path: C:\pp\bin\i386-win32>path PATH=C:\pp\bin\i386-win32;C:\Program Files . So, at least this error message is wrong. The "Create new Fppkg configuration" is disabled. How to proceed from here? -- Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On 3/19/19 2:06 PM, Joost van der Sluis wrote: On 3/19/19 11:35 AM, Mattias Gaertner via fpc-pascal wrote: On Tue, 19 Mar 2019 11:17:42 +0100 Joost van der Sluis wrote: [...] Probably it fails because I have old 2.6.4 fppkg configs. I ran the samplecfg, which said it would create ~/.fpc.cfg, ~/.fp, ... Then the error was gone. I restored the files from backup. Initial dialog pops up with error. But to my surprise the create config button worked. So apparently samplecfg changes more files than it claims. I have to find out what it does. This was useful information. I have the same error-message now. Do you also have something like this in your fppkg.cfg? (The one that fails) Path=/home/CNOC/joost/fpc/lib/fpc/{CompilerVersion}//{CompilerVersion}/ (Note the duplicate {CompilerVersion} ?) Not so easy to solve, though. I can imagine that some people do have FPC installed in a directory that does not contain the compiler-version. So I'll have to adapt fpcmkcfg... On a second look it seems that this problem has been resolved already. Did you have an old version of fpcmkcfg, maybe? I'll add a check for that. Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On 3/19/19 11:35 AM, Mattias Gaertner via fpc-pascal wrote: On Tue, 19 Mar 2019 11:17:42 +0100 Joost van der Sluis wrote: [...] Probably it fails because I have old 2.6.4 fppkg configs. I ran the samplecfg, which said it would create ~/.fpc.cfg, ~/.fp, ... Then the error was gone. I restored the files from backup. Initial dialog pops up with error. But to my surprise the create config button worked. So apparently samplecfg changes more files than it claims. I have to find out what it does. This was useful information. I have the same error-message now. Do you also have something like this in your fppkg.cfg? (The one that fails) Path=/home/CNOC/joost/fpc/lib/fpc/{CompilerVersion}//{CompilerVersion}/ (Note the duplicate {CompilerVersion} ?) Not so easy to solve, though. I can imagine that some people do have FPC installed in a directory that does not contain the compiler-version. So I'll have to adapt fpcmkcfg... Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On Tue, 19 Mar 2019 11:17:42 +0100 Joost van der Sluis wrote: >[...] > > Probably it fails because I have old 2.6.4 fppkg configs. I ran the samplecfg, which said it would create ~/.fpc.cfg, ~/.fp, ... Then the error was gone. I restored the files from backup. Initial dialog pops up with error. But to my surprise the create config button worked. So apparently samplecfg changes more files than it claims. I have to find out what it does. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On 3/18/19 11:21 PM, Mattias Gaertner via fpc-pascal wrote: On Mon, 18 Mar 2019 22:04:17 +0100 Joost van der Sluis wrote: Definitely. It would be even better to tell the full file name. e.g. /etc/fpcpkg.cfg. Problem is that it could also be in the fppkg-compiler configuration file (by default called default). But it could also be something else. To be honest, I don't have a clue why it does not work for you. That's my problem too. That's why I'm asking for a better error message. I can not give a better error-message, if I do not even know myself what the problem of your configuration is. One guess would be that you do not have the fpmkunit-directory available. It would be extremely helpful, if it would check common mistakes, like this. An error message "Directory /path/fpmkunit is missing. Check your /etc/fpcpkg.cfg." would be far better than "Error: the Fppkg configuration is corrupt." What is corrupt? Is something missing, too much, not readable, did a command fail? What did it check to come to this conclusion? It already does all checks I can think of. And it does have special messages for all those cases. But, as long as I do not know what the problem is that you or others are experiencing, I can not give a better message. The message you see is the last message, when it failes but the system has no clue why. Maybe I should change this message to what is exactly happens, that it can not find the rtl. But this was the message in the past, leading to all kind of complains like: 'But the RTL is just there!'. We have to find the right message. It also took a while until we found the right text for the other problems in this dialog. But first I have to know what your issue actually is. Does not work. Can you elaborate, what it should do? Call samplecfg. ;) The dialog checks if the given prefix is valid. (It checks for the existence of a few files) Lazarus does similar checks with fpc. Some fpc version changed some paths, some platforms have different files. Boom, the user gets a wrong error message. That's why the IDE should tell exactly, what it checked. When it can not find those files, it will tell you so. Just like the other screens do. Just type something on the combobox with the prefix, it will give you hints until the path is probably right. When you click on the button to create the new configuration-file, it calls 'fpcmkcfg -3' and 'fpcmkcfg -4' with the parameters deducted from the given prefix. Just like samplecfg on Linux does. After this, it re-loads fppkg. And it checks if the rtl-package can be found. If this is not the case, it complains. So, can you give the output of 'fppkg listsettings' and 'fppkg list -d', to check why it can not find the rtl? Probably it fails because I have old 2.6.4 fppkg configs. It should be able to handle those. And even when not, fpcmkcfg should just overwrite those. Another guess would be: it uses an old version of fpcmkcfg. Older versions need other parameters for it to work. But it seaches for fpcmkcfg at the same location it finds the compiler. So when you did do a 'make install', it should use the latest version. How do your fppkg.cfg and default files looks like? After the re-create that is? Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On Mon, 18 Mar 2019 22:04:17 +0100 Joost van der Sluis wrote: >[...] > > If fppkg.cfg is the cause, why does the Lazarus initial setup not > > tell this? > > I found it difficult to come up with a descriptive message. > > Do you think that "fppkg.cfg" is better then "fppkg configuration"? Definitely. It would be even better to tell the full file name. e.g. /etc/fpcpkg.cfg. > Problem is that it could also be in the fppkg-compiler configuration > file (by default called default). But it could also be something > else. To be honest, I don't have a clue why it does not work for you. That's my problem too. That's why I'm asking for a better error message. > One guess would be that you do not have the fpmkunit-directory > available. It would be extremely helpful, if it would check common mistakes, like this. An error message "Directory /path/fpmkunit is missing. Check your /etc/fpcpkg.cfg." would be far better than "Error: the Fppkg configuration is corrupt." What is corrupt? Is something missing, too much, not readable, did a command fail? What did it check to come to this conclusion? Or if it does not fit into a one or two sentences, you can give a link "See here how to setup fppkg http://wiki.freepascal.org/...;. Same with "Failed to create a new Fppkg configuration. You will have to fix the configuration manually or reinstall Free Pascal." What did it try? What command failed? > >> Use samplecfg to do that: > >> > >> sh compiler/utils/samplecfg /usr/local/lib/fpc/3.3.1 As root that would overwrite my /etc/fpc.cfg As normal user it creates /home/mattias/.fpc.cfg > > Or this? > > > > > >> Btw: you can also use the button in Lazarus in the initial > >> configuration screen which will essentially do the same. At least > >> is should. > > > > Does not work. Can you elaborate, what it should do? > > Call samplecfg. ;) > > The dialog checks if the given prefix is valid. (It checks for the > existence of a few files) Lazarus does similar checks with fpc. Some fpc version changed some paths, some platforms have different files. Boom, the user gets a wrong error message. That's why the IDE should tell exactly, what it checked. > It has some hard-coded paths to check for > to fill the combobox, and it extracts the prefix from the given > compiler-executable. It guessed the prefix correctly. > When you click on the button to create the new configuration-file, it > calls 'fpcmkcfg -3' and 'fpcmkcfg -4' with the parameters deducted > from the given prefix. Just like samplecfg on Linux does. > > After this, it re-loads fppkg. And it checks if the rtl-package can > be found. If this is not the case, it complains. > > So, can you give the output of 'fppkg listsettings' and 'fppkg list > -d', to check why it can not find the rtl? Probably it fails because I have old 2.6.4 fppkg configs. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
Op 18-03-19 om 18:20 schreef Mattias Gaertner via fpc-pascal: On Mon, 18 Mar 2019 17:02:35 +0100 Joost van der Sluis wrote: Op 15-03-19 om 22:48 schreef Mattias Gaertner via fpc-pascal: How to install fpc 3.3.1? When I use make install under Linux, Lazarus complains: Error: the Fppkg configuration is corrupt. I can compile everything without errors. "Make install" does not create any configuration-files (like fpc.cfg and fppkg.cfg). If fppkg.cfg is the cause, why does the Lazarus initial setup not tell this? I found it difficult to come up with a descriptive message. Do you think that "fppkg.cfg" is better then "fppkg configuration"? Problem is that it could also be in the fppkg-compiler configuration file (by default called default). But it could also be something else. To be honest, I don't have a clue why it does not work for you. One guess would be that you do not have the fpmkunit-directory available. Use samplecfg to do that: sh compiler/utils/samplecfg /usr/local/lib/fpc/3.3.1 Or this? Btw: you can also use the button in Lazarus in the initial configuration screen which will essentially do the same. At least is should. Does not work. Can you elaborate, what it should do? Call samplecfg. ;) The dialog checks if the given prefix is valid. (It checks for the existence of a few files) It has some hard-coded paths to check for to fill the combobox, and it extracts the prefix from the given compiler-executable. When you click on the button to create the new configuration-file, it calls 'fpcmkcfg -3' and 'fpcmkcfg -4' with the parameters deducted from the given prefix. Just like samplecfg on Linux does. After this, it re-loads fppkg. And it checks if the rtl-package can be found. If this is not the case, it complains. So, can you give the output of 'fppkg listsettings' and 'fppkg list -d', to check why it can not find the rtl? Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
On Mon, 18 Mar 2019 17:02:35 +0100 Joost van der Sluis wrote: > Op 15-03-19 om 22:48 schreef Mattias Gaertner via fpc-pascal: > > How to install fpc 3.3.1? > > > > When I use make install under Linux, Lazarus complains: > > Error: the Fppkg configuration is corrupt. > > > > I can compile everything without errors. > > "Make install" does not create any configuration-files (like fpc.cfg > and fppkg.cfg). If fppkg.cfg is the cause, why does the Lazarus initial setup not tell this? > Use samplecfg to do that: > > sh compiler/utils/samplecfg /usr/local/lib/fpc/3.3.1 Or this? > Btw: you can also use the button in Lazarus in the initial > configuration screen which will essentially do the same. At least is > should. Does not work. Can you elaborate, what it should do? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] bug in make install ?
Op 15-03-19 om 22:48 schreef Mattias Gaertner via fpc-pascal: How to install fpc 3.3.1? When I use make install under Linux, Lazarus complains: Error: the Fppkg configuration is corrupt. I can compile everything without errors. "Make install" does not create any configuration-files (like fpc.cfg and fppkg.cfg). Use samplecfg to do that: sh compiler/utils/samplecfg /usr/local/lib/fpc/3.3.1 Btw: you can also use the button in Lazarus in the initial configuration screen which will essentially do the same. At least is should. Regards, Joost. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] bug in make install ?
Hi, How to install fpc 3.3.1? When I use make install under Linux, Lazarus complains: Error: the Fppkg configuration is corrupt. I can compile everything without errors. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in documentation for Random?
On 05/04/17 17:55, Bart wrote: > http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Random > > "random returns a random number between 0 and abs(num-1)" > > IIUC, then Random() shoud always return a positive number. > Mmm, I don't think so: For y := Random(num); the unsigned value of 'y' will will between 0 and abs(num-1) - inclusive, but then, the value returned keeps the sign of num; (this as per FPC implementation) I like Giuliano's definition, it is brief and beautiful: >> Random(L) returns a random number in the range 0 (included) to L >> (excluded). (maybe with a similarly brief and concise remark: 'regardless of the sign of L' > Bart -L. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in documentation for Random?
Usualy "non-negative", not positive ! Cheers, Ched' Le 05.04.2017 à 16:55, Bart a écrit : http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Random "random returns a random number between 0 and abs(num-1)" IIUC, then Random() shoud always return a positive number. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in documentation for Random?
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Random "random returns a random number between 0 and abs(num-1)" IIUC, then Random() shoud always return a positive number. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in documentation for Random?
Fun fact: TP's random used an unsigned parameter (word), so no ambiguity there. Random (function) -- Returns a random number. Declaration: function Random [ ( Range: Word) ]: < Same type as parameter >; Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in documentation for Random?
On 4/5/17, Santiago A.wrote: > random(-10) > will output numbres -9..0 That was not realy the question. The question is wether the documentation is wrong, or the implementation or neither. B.t.w. Delphi7 gives me: Random(-10) = -776108169 Random(-10) = 244426112 Random(-10) = -1774796928 Random(-10) = 1443026331 Random(-10) = -919853036 Random(-10) = -747947900 Random(-10) = -1767321924 Random(-10) = -2114448955 Random(-10) = 1499268340 Random(-10) = -1658783534 (which makes no sense at all to me...) Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in documentation for Random?
Il 05/04/2017 18:09, Bart ha scritto: http://www.freepascal.org/docs-html/current/rtl/system/random.html "Random returns a random number larger or equal to 0 and strictly less than L" However random(a negative number) returns a number <= 0 and > L program r; begin randomize; writeln('Random(-10) = ',Random(-10)); end. C:\Users\Bart\LazarusProjecten>test random(-10) = -1 C:\Users\Bart\LazarusProjecten>test random(-10) = -4 Maybe my understanding of English ("strictly less than") is not correct, so I ask here before posting as a bugreport. My scant knowledge of English leads me to believe that the sentence should be rephrased in order to cover the negative numbers case: either: Random return a random number with the same sign of L, and whose absolute value is larger or equal to zero and strictly less than the absolute value of L. or: Random return a random number in the range 0 (included) to L (excluded). Just my 2c. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in documentation for Random?
El 05/04/2017 a las 18:09, Bart escribió: > http://www.freepascal.org/docs-html/current/rtl/system/random.html > > "Random returns a random number larger or equal to 0 and strictly less than L" > > However random(a negative number) returns a number <= 0 and > L > > > program r; > begin > randomize; > writeln('Random(-10) = ',Random(-10)); > end. > > C:\Users\Bart\LazarusProjecten>test > random(-10) = -1 > C:\Users\Bart\LazarusProjecten>test > random(-10) = -4 > > Maybe my understanding of English ("strictly less than") is not > correct, so I ask here before posting as a bugreport. I've never used negative values, so this is just a guess: random(+10) will output numbres 0..9 random(-10) will output numbres -9..0 so, it is equivalent to -random(10) -- Saludos Santi s...@ciberpiula.net ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Bug in documentation for Random?
http://www.freepascal.org/docs-html/current/rtl/system/random.html "Random returns a random number larger or equal to 0 and strictly less than L" However random(a negative number) returns a number <= 0 and > L program r; begin randomize; writeln('Random(-10) = ',Random(-10)); end. C:\Users\Bart\LazarusProjecten>test random(-10) = -1 C:\Users\Bart\LazarusProjecten>test random(-10) = -4 Maybe my understanding of English ("strictly less than") is not correct, so I ask here before posting as a bugreport. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Am 24.02.2016 16:44 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > Bo Berglund wrote: >> >> On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth >>wrote: >>> >>> What would really help here would be the warning that Jonas mentioned... >>> For the above you could just use a local variable and be done with it. No >>> need to try to "fix" the with-statement. >> >> >> I really fully agree! > > > Perhaps a hint when a single WITH is used and a warning if they're nested. After all, it /is/ a standard part of the language. A warning when another identifier is shadowed might be more useful as Jonas said. Cause then one could find all problematic identifiers and not just all withs... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Am 24.02.2016 12:30 schrieb "Bo Berglund": > > On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth > wrote: > > > >What would really help here would be the warning that Jonas mentioned... > >For the above you could just use a local variable and be done with it. No > >need to try to "fix" the with-statement. > > I really fully agree! > When working a few years back I had to trace through a piece of code > where the original author had done something like: > > with My.Stuff.something do > with My.Other.Stuff.somethingelse do > with myyetanother do > begin > someproperty := xxx; > > > end; > It was totally impossible to make sense of anything while debugging! Just as a sidenote: Lazarus handles withs correctly while debugging ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Bo Berglund wrote: On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barthwrote: What would really help here would be the warning that Jonas mentioned... For the above you could just use a local variable and be done with it. No need to try to "fix" the with-statement. I really fully agree! Perhaps a hint when a single WITH is used and a warning if they're nested. After all, it /is/ a standard part of the language. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
etrusco wrote > I loved 'with' while I was learning Delphi/Pascal and hated after the > first few months since using it professionaly. I truly believe it > warrants/deserves some advice in the documentation, for the beginners. > With the code completion in Lazarus there's even less reason to use it > - besides any possibly missing compiler optimization... Indeed, there are no big differences between "uses" and "with" in Object Pascal, "using namespace" in C++ or "using" in C#. For example, my short article "Crack C# namespaces in 30 seconds" http://arbinada.com/main/en/node/1416 - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724311.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Wed, Feb 24, 2016 at 9:00 AM, Michael Van Canneytwrote: > > > On Wed, 24 Feb 2016, Flávio Etrusco wrote: > >> On Wed, Feb 24, 2016 at 8:39 AM, Marco van de Voort >> wrote: >>> >>> In our previous episode, Mark Morgan Lloyd said: > (remember recent discussion about IfThen pseudo-function). More relevant to your situation, I remember discussion about adding an identifier to WITH to use as an explicit shortcut, i.e. something like with foo= bar do foo.someField := ... >>> >>> >>> Not relevant since the With code in this case must remain delphi >>> compatible. >> >> >> I, for one, would vote in favor making the documentation discourage >> the use of 'with' and adding a warning in compiler... > > > I don't see why. > > I use "with" extensively. I see nothing wrong with this useful construct. > > The problem of the 'new identifier inserted in scope' exists, but is rare > enough for me to tip the balance in favour of using "with". It has maybe > happened once or twice in 25 years that I got bitten by it. > > I find that perfectly acceptable. > > For people that worry about this, the solution of Jonas should be ample to > detect/avoid mistakes. > > Michael. I loved 'with' while I was learning Delphi/Pascal and hated after the first few months since using it professionaly. I truly believe it warrants/deserves some advice in the documentation, for the beginners. With the code completion in Lazarus there's even less reason to use it - besides any possibly missing compiler optimization... Best regards, Flávio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Good, I see yours points. Not so impressed, don't really share. The community spirit does not inspire confidence. I stay with FPC/Lazarus for some fun projects like FBProfiler (https://sourceforge.net/projects/fbprofiler/) but for "real world programs" the migration is canceled until better times. - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724309.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Wed, 24 Feb 2016, Flávio Etrusco wrote: On Wed, Feb 24, 2016 at 8:39 AM, Marco van de Voortwrote: In our previous episode, Mark Morgan Lloyd said: > (remember recent discussion about IfThen pseudo-function). More relevant to your situation, I remember discussion about adding an identifier to WITH to use as an explicit shortcut, i.e. something like with foo= bar do foo.someField := ... Not relevant since the With code in this case must remain delphi compatible. I, for one, would vote in favor making the documentation discourage the use of 'with' and adding a warning in compiler... I don't see why. I use "with" extensively. I see nothing wrong with this useful construct. The problem of the 'new identifier inserted in scope' exists, but is rare enough for me to tip the balance in favour of using "with". It has maybe happened once or twice in 25 years that I got bitten by it. I find that perfectly acceptable. For people that worry about this, the solution of Jonas should be ample to detect/avoid mistakes. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Wed, Feb 24, 2016 at 8:39 AM, Marco van de Voortwrote: > In our previous episode, Mark Morgan Lloyd said: >> > (remember recent discussion about IfThen pseudo-function). >> >> More relevant to your situation, I remember discussion about adding an >> identifier to WITH to use as an explicit shortcut, i.e. something like >> >> with foo= bar do >>foo.someField := ... > > Not relevant since the With code in this case must remain delphi compatible. I, for one, would vote in favor making the documentation discourage the use of 'with' and adding a warning in compiler... Best regards, Flávio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
In our previous episode, Mark Morgan Lloyd said: > > (remember recent discussion about IfThen pseudo-function). > > More relevant to your situation, I remember discussion about adding an > identifier to WITH to use as an explicit shortcut, i.e. something like > > with foo= bar do >foo.someField := ... Not relevant since the With code in this case must remain delphi compatible. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barthwrote: > >What would really help here would be the warning that Jonas mentioned... >For the above you could just use a local variable and be done with it. No >need to try to "fix" the with-statement. I really fully agree! When working a few years back I had to trace through a piece of code where the original author had done something like: with My.Stuff.something do with My.Other.Stuff.somethingelse do with myyetanother do begin someproperty := xxx; end; It was totally impossible to make sense of anything while debugging! WITH should be abolished in my view! I had to make local variables to shorten down the length of the identifiers and then put the correct variable in front like: MS.someproperty := xxx; Only then was it possible to inspect the values while debugging. Further: I see every other day in the Embarcadero forum comments by Remy Lebeau where he strongly advices against using WITH. Only goes to show that it plagues Delphi as well. Join the crusade against WITH!!! -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Am 23.02.2016 23:28 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > Serguei TARASSOV wrote: > >> There is no perfect way so why the language extension is the safest >> (remember recent discussion about IfThen pseudo-function). > > > More relevant to your situation, I remember discussion about adding an identifier to WITH to use as an explicit shortcut, i.e. something like > > with foo= bar do > foo.someField := ... > What would really help here would be the warning that Jonas mentioned... For the above you could just use a local variable and be done with it. No need to try to "fix" the with-statement. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Serguei TARASSOV wrote: There is no perfect way so why the language extension is the safest (remember recent discussion about IfThen pseudo-function). More relevant to your situation, I remember discussion about adding an identifier to WITH to use as an explicit shortcut, i.e. something like with foo= bar do foo.someField := ... -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On 23.02.2016 17:21, Serguei TARASSOV wrote: > Michael Van Canneyt wrote >> I hope you will send the same mail to embarcadero/Idera. >> When they added methods to TPoint, they broke have the VCL code ? >> >> To avoid this, we would need to freeze the code as soon as it is released. > > Compared with Unicode migration, introducing the methods into records is not > breaking :) Adding methods to the TPoint or TRect record is *exactly* like adding a method/property to TField. If you use "with" you might find yourself in a dangerous/problematic situation. That *did* happen with various code after we introduced the new methods to TPoint and TRect. > The code is not frozen but for the core level units the modifications are > rare and very risky without vast codebase and testing. > DB is a vary mature unit, almost all DACs based on it so 100% compatibility > with Delphi does matter. And the DB code is Delphi compatible. But if you (as in "general you") are using a feature that is *known* to lead to problems if fields and properties are added then that's your own problem. From great power comes great responsibility. We take backwards compatibility very serious, but there has to be a line drawn somewhere. > However, there are some useful methods to extend: > - subclassing (the safest) > - class helpers > - property/method's attributes (need to be introduced at compiler level) > - interfaces (when creating new interface for every extension) And to burden everyone else with the need to e.g. include a unit with a helper restricting them from adding their own if they don't derive from the original helper? No thank you. We are no slaves to Delphi. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Michael Van Canneyt wrote > I hope you will send the same mail to embarcadero/Idera. > When they added methods to TPoint, they broke have the VCL code ? > > To avoid this, we would need to freeze the code as soon as it is released. Compared with Unicode migration, introducing the methods into records is not breaking :) The code is not frozen but for the core level units the modifications are rare and very risky without vast codebase and testing. DB is a vary mature unit, almost all DACs based on it so 100% compatibility with Delphi does matter. However, there are some useful methods to extend: - subclassing (the safest) - class helpers - property/method's attributes (need to be introduced at compiler level) - interfaces (when creating new interface for every extension) I.e. adding attribute "new" to property/method the compiler will generate the error when conflicting to resolve names in existing code. There is no perfect way so why the language extension is the safest (remember recent discussion about IfThen pseudo-function). - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724291.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On 2016-02-23 14:13, Mark Morgan Lloyd wrote: > And the extra typechecks etc. mean that FPC is a bit better than most > language implementations at catching things like that. Exactly. I prefer getting an error so I can fix my code and know it will work as intended - instead of the compiler silently working around the problem and possibly producing incorrect result (only noticed months down the line). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Graeme Geldenhuys wrote: On 2016-02-23 10:54, Serguei TARASSOV wrote: I see, but *it's not my code*, its a code of the big third-party framework that is working well with all version of Delphi/C++ builder and Lazarus 1.x with FPC 2.6.4. Well, now it doesn't work with FPC 3.0. ;-) You cannot recommend them to change code. Why not. Many 3rd party libraries need to update there code for newer Delphi and FPC releases. This is just one of those cases. This is not ever limited to the Object Pascal language, it affects any programming language. And the extra typechecks etc. mean that FPC is a bit better than most language implementations at catching things like that. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
I have the latest version of Devart pgdac and virtualtable.pas compiles fine. On Feb 23, 2016 3:33 AM, "Serguei TARASSOV"wrote: > Hello, > > Sorry, my previous example was not complete. > Here is a problem detected when compiling UniDAC 6.2.8. > Taken from real code in VirtualTable.pas > > program Project1; > > {$MODE DELPHI} > > uses > SysUtils, Classes, DB; > > procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs); > var > F: TField; > FieldDef: TFieldDef; > begin > begin > with F do > begin > FieldDef := FieldDefs.AddFieldDef; > // in FPC 3.0.0 Error: No member is provided to access property > // in FPC 2.6.4 compiles OK > end; > end; > end; > > begin > end. > > > > > - > -- > Regards, > Serguei > -- > View this message in context: > http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274.html > Sent from the Free Pascal - General mailing list archive at Nabble.com. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Henry Vermaak wrote on Tue, 23 Feb 2016: On Tue, Feb 23, 2016 at 02:13:52PM +0100, Jonas Maebe wrote: It would probably be useful if we added support to the compiler to generate a warning (or even error) in case a with statement hides an existing symbol in scope though. Yes, please. Something like -Wshadow would be very useful. That already exists and is enabled by default for local variables and parameter names hiding fields. It even gives errors in FPC and ObjFPC modes, rather than warnings. It's just not (yet) implemented for with-statements (and local variables or fields hiding global variables, but that's a different matter). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, Feb 23, 2016 at 02:13:52PM +0100, Jonas Maebe wrote: > It would probably be useful if we added support to the compiler to > generate a warning (or even error) in case a with statement hides an > existing symbol in scope though. Yes, please. Something like -Wshadow would be very useful. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, 23 Feb 2016, Serguei TARASSOV wrote: Okay, okay, I see. For info, the indicated error is not critical because of its visibility at compile-time. All other codes inside "with" statement like x := FieldDef; will be compiled without errors and should be checked. Thank you, guys, for a good compatibility support and adding the features to the principal units that break the existing code of "real world programs". I hope you will send the same mail to embarcadero/Idera. When they added methods to TPoint, they broke have the VCL code ? To avoid this, we would need to freeze the code as soon as it is released. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Serguei TARASSOV wrote on Tue, 23 Feb 2016: Thank you, guys, for a good compatibility support Come on. The only way this kind of problems can be avoided is by us never adding any new field or property to any class, ever. It would probably be useful if we added support to the compiler to generate a warning (or even error) in case a with statement hides an existing symbol in scope though. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Okay, okay, I see. For info, the indicated error is not critical because of its visibility at compile-time. All other codes inside "with" statement like x := FieldDef; will be compiled without errors and should be checked. Thank you, guys, for a good compatibility support and adding the features to the principal units that break the existing code of "real world programs". - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724281.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, 23 Feb 2016, Graeme Geldenhuys wrote: On 2016-02-23 10:54, Serguei TARASSOV wrote: I see, but *it's not my code*, its a code of the big third-party framework that is working well with all version of Delphi/C++ builder and Lazarus 1.x with FPC 2.6.4. Well, now it doesn't work with FPC 3.0. ;-) You cannot recommend them to change code. Why not. Many 3rd party libraries need to update there code for newer Delphi and FPC releases. This is just one of those cases. This is not ever limited to the Object Pascal language, it affects any programming language. Exactly. See e.g. the recent changes in TPoint, which necessitated a lot of changes in the LCL, because "with" was used a lot. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On 2016-02-23 10:54, Serguei TARASSOV wrote: > I see, but *it's not my code*, its a code of the big third-party framework > that is working well with all version of Delphi/C++ builder and Lazarus 1.x > with FPC 2.6.4. Well, now it doesn't work with FPC 3.0. ;-) > You cannot recommend them to change code. Why not. Many 3rd party libraries need to update there code for newer Delphi and FPC releases. This is just one of those cases. This is not ever limited to the Object Pascal language, it affects any programming language. Plus, it's another excellent example of why you shouldn't use WITH. I don't care how many disagree with me, I always thought it a bad language design. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, 23 Feb 2016, Serguei TARASSOV wrote: Michael Van Canneyt wrote The problem is in your code and the use of WITH, as I surmised in my previous mail. In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef. The code compiles ok. In 3.0.0, FieldDef is a NEW READ-ONLY property in TField. Because of the WITH, the compiler resolves FieldDef to this property, but it is read-only, an so it gives an error. I see, but *it's not my code*, its a code of the big third-party framework that is working well with all version of Delphi/C++ builder and Lazarus 1.x with FPC 2.6.4. You cannot recommend them to change code. If course I can, I just did. The mode Delphi is declared. The mode is entirely irrelevant. It should be compatible. We introduced the FieldDef property in TField. This was a conscious decision. They chose to use "with", and then this kind of thing can happen at any point. So, they must adapt their code. Don't use "with" if you're not prepared to deal with such issues. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Michael Van Canneyt wrote > The problem is in your code and the use of WITH, as I surmised in my > previous mail. > > In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef. > The code compiles ok. > > In 3.0.0, FieldDef is a NEW READ-ONLY property in TField. > Because of the WITH, the compiler resolves FieldDef to this property, but > it > is read-only, an so it gives an error. I see, but *it's not my code*, its a code of the big third-party framework that is working well with all version of Delphi/C++ builder and Lazarus 1.x with FPC 2.6.4. You cannot recommend them to change code. There are many other errors during compile, if someone is interesting I can provide the list. So the problem is in DB unit. The mode Delphi is declared. It should be compatible. - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724276.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, 23 Feb 2016, Serguei TARASSOV wrote: Hello, Sorry, my previous example was not complete. Here is a problem detected when compiling UniDAC 6.2.8. Taken from real code in VirtualTable.pas program Project1; {$MODE DELPHI} uses SysUtils, Classes, DB; procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs); var F: TField; FieldDef: TFieldDef; begin begin with F do begin FieldDef := FieldDefs.AddFieldDef; // in FPC 3.0.0 Error: No member is provided to access property // in FPC 2.6.4 compiles OK The problem is in your code and the use of WITH, as I surmised in my previous mail. In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef. The code compiles ok. In 3.0.0, FieldDef is a NEW READ-ONLY property in TField. Because of the WITH, the compiler resolves FieldDef to this property, but it is read-only, an so it gives an error. Change your code to Var AFieldDef: TFieldDef; and AFieldDef := FieldDefs.AddFieldDef; and all will be well. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Hello, Sorry, my previous example was not complete. Here is a problem detected when compiling UniDAC 6.2.8. Taken from real code in VirtualTable.pas program Project1; {$MODE DELPHI} uses SysUtils, Classes, DB; procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs); var F: TField; FieldDef: TFieldDef; begin begin with F do begin FieldDef := FieldDefs.AddFieldDef; // in FPC 3.0.0 Error: No member is provided to access property // in FPC 2.6.4 compiles OK end; end; end; begin end. - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0?
Error: (3059) No member is provided to access property is because TField.FieldDef is defined like: Property FieldDef : TFieldDef Read FFieldDef; so there is no write method from begining (2 years ago rev. 26776). Error: (5000) Identifier not found "FieldDefs" FieldDefs is property of TDataSet, not TField so it can not work in your example (also Delphi has FieldDefs as property of TDataSet) -Laco. Hello, UniDAC doesn't compile with Lazarus 1.6/FPC 3.0. The case may be reproduced on following example. program Project1; {$MODE DELPHI} uses SysUtils, Classes, DB; var F: TField; FieldDef: TFieldDef; begin with F do FieldDef := FieldDefs.AddFieldDef; // ^^error here end. Free Pascal Compiler version 3.0.0 [2016/02/14] for i386 Copyright (c) 1993-2015 by Florian Klaempfl and others (1002) Target OS: Win32 for i386 (3104) Compiling C:\Users\serge\AppData\Local\Temp\project1.lpr project1.lpr(13,13) Error: (3059) No member is provided to access property project1.lpr(13,16) Error: (5000) Identifier not found "FieldDefs" project1.lpr(16) Fatal: (10026) There were 2 errors compiling module, stopping Fatal: (1018) Compilation aborted Error: C:\lazarus\fpc\3.0.0\bin\i386-win32\ppc386.exe returned an error exitcode - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-tp5724260.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0?
On Mon, 22 Feb 2016, Serguei TARASSOV wrote: Michael Van Canneyt wrote On Mon, 22 Feb 2016, Serguei TARASSOV wrote: Hello, UniDAC doesn't compile with Lazarus 1.6/FPC 3.0. The case may be reproduced on following example. To my knowledge, this has never worked. Michael. History log is below :) Well, the compiler is on my side: home: >ppcx64-2.6 td.pp td.pp(13,34) Error: Identifier not found "FieldDefs" td.pp(16,16) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted home: >ppcx64-2.6.4 td.pp td.pp(13,34) Error: Identifier not found "FieldDefs" td.pp(16,16) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted I suspect some refactoring in UniDAC is the cause of your problem. A "with" gone wrong ? Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0?
Michael Van Canneyt wrote > On Mon, 22 Feb 2016, Serguei TARASSOV wrote: > >> Hello, >> >> UniDAC doesn't compile with Lazarus 1.6/FPC 3.0. >> The case may be reproduced on following example. > > To my knowledge, this has never worked. > > Michael. History log is below :) UniDAC 6.1 compiles OK with FPC 2.6.4 But the same sources of UniDAC 6.1 doesn't compile with FPC 3.0 Upgrading, but UniDAC 6.2 doesn't compile with FPC 3.0 too So I will see tomorrow UniDAC 6.2 with FPC 2.6.4 to provide more info. - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-tp5724260p5724264.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal