Re: [fpc-pascal] Bug or feature ?

[Sven Barth via fpc-pascal]

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 ?

[Ched via fpc-pascal]

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 ?

[DougC via fpc-pascal]

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 ?

[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 ?


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?

[Elmar Haneke via fpc-pascal]

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?

[Michael Van Canneyt via fpc-pascal]

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?

[Florian Klämpfl via fpc-pascal]

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?

[Sven Barth via fpc-pascal]

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?

[Michael Van Canneyt via fpc-pascal]

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?

[Mattias Gaertner via fpc-pascal]

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?

[Michael Van Canneyt via fpc-pascal]

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?

[Ryan Joseph via fpc-pascal]

> 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?

[Mattias Gaertner via fpc-pascal]

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?

[Jonas Maebe via fpc-pascal]

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?

[Michael Van Canneyt via fpc-pascal]

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?

[Jonas Maebe via fpc-pascal]

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?

[Michael Van Canneyt via fpc-pascal]

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?

[Sven Barth via fpc-pascal]

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?

[Michael Van Canneyt via fpc-pascal]

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?

[Mattias Gaertner via fpc-pascal]

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

[Sven Barth via fpc-pascal]

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

[Michael Van Canneyt via fpc-pascal]

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

[Mattias Gaertner via fpc-pascal]

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)

[Christo Crause via fpc-pascal]

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)

[Michael Van Canneyt via fpc-pascal]

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)

[Christo Crause via fpc-pascal]

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)

[Dmitry Boyarintsev via fpc-pascal]

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

[Joost van der Sluis]

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

[Michael Van Canneyt]

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

[Noel Duffy via fpc-pascal]

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

[Noel Duffy via fpc-pascal]

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

[Michael Van Canneyt]

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

[Michael Van Canneyt]

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

[Jonas Maebe]

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

[Noel Duffy via fpc-pascal]

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

[Michael Van Canneyt]

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

[Noel Duffy via fpc-pascal]

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

[Michael Van Canneyt]

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

[Noel Duffy via fpc-pascal]

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

[Mgr. Janusz Chmiel]

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 ?

[Bart]

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 ?

[Cyrax]

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 ?

[Bart]

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 ?

[Bart]

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 ?

[Bart]

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 ?

[Joost van der Sluis]

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 ?

[Bart]

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 ?

[Joost van der Sluis]

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 ?

[Joost van der Sluis]

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 ?

[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

-- 
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 ?

[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."

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 ?

[Bart]

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 ?

[Joost van der Sluis]

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 ?

[Joost van der Sluis]

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 ?

[Mattias Gaertner via fpc-pascal]

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 ?

[Joost van der Sluis]

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 ?

[Mattias Gaertner via fpc-pascal]

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 ?

[Joost van der Sluis]

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 ?

[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?


> 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 ?

[Joost van der Sluis]

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 ?

[Mattias Gaertner via fpc-pascal]

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?

[Lukasz Sokol]

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?

[Ched]

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?

[Bart]

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?

[Bart]

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?

[Bart]

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?

[Giuliano Colla]

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?

[Santiago A.]

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?

[Bart]

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?)

[Sven Barth]

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?)

[Sven Barth]

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?)

[Mark Morgan Lloyd]

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.


--
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?)

[Serguei TARASSOV]

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?)

[Flávio Etrusco]

On Wed, Feb 24, 2016 at 9:00 AM, Michael Van Canneyt
 wrote:
>
>
> 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?)

[Serguei TARASSOV]

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?)

[Michael Van Canneyt]

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.___
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?)

[Flávio Etrusco]

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...

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?)

[Marco van de Voort]

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?)

[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!

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?)

[Sven Barth]

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?)

[Mark Morgan Lloyd]

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?)

[Sven Barth]

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?)

[Serguei TARASSOV]

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?)

[Graeme Geldenhuys]

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?)

[Mark Morgan Lloyd]

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?)

[Tony Caduto]

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?)

[Jonas Maebe]

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?)

[Henry Vermaak]

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?)

[Michael Van Canneyt]

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?)

[Jonas Maebe]

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?)

[Serguei TARASSOV]

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?)

[Michael Van Canneyt]

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?)

[Graeme Geldenhuys]

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?)

[Michael Van Canneyt]

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?)

[Serguei TARASSOV]

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?)

[Michael Van Canneyt]

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?)

[Serguei TARASSOV]

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?

[LacaK]

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?

[Michael Van Canneyt]

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?

[Serguei TARASSOV]

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