Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2010-10

Fatal: Internal error 200111022

12 messages · 5 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Birger Jansen

I'm not sure if this is the correct way to report this, please correct me if I should report in another way.

I found an old conversation between Leonardo and Florian about the Fatail internal error 200111022. The thread concluded that they could not reproduce the error.

I got this error while converting a large project from Delphi to FPC. It turns out that a base class has a property Count, and a derived class has a function with the same name Count. This will compile, untill you call the property or function Count.

I created an example that should explain it. Uncomment the marked line to get the fatal internal error:

program project1;
{$mode objfpc}{$H+}
uses
  {$IFDEF UNIX}{$IFDEF UseCThreads}
  cthreads,
  {$ENDIF}{$ENDIF}
  Classes;
type
  TBase = class
  private
    function GetCount: Integer;
  public
    property Count: Integer read GetCount;
  end;
  TSub = class(TBase)
  public
    function Count: Integer; overload;
  end;
function TSub.Count: Integer;
begin
  Result := 0;
end;

{ TBase }

function TBase.GetCount: Integer;
begin
  Result := 0;
end;
var
  MySub: TSub;
  i : Integer;
begin
  MySub := TSub.Create;
// uncomment the next line for Fatal Internal error 200111022:
//  for i := 0 to MySub.Count do begin end;
end.

Reply by email

Michael Van Canneyt
to Birger Jansen

Hello,

Which 'Count' should the compiler select ? I suspect TSub.Count ?

I think we should prohibit this dubious construct in ObjFC mode. (but try to be delphi compatible in Delphi mode)

Michael.

Birger Jansen wrote 56 lines
I'm not sure if this is the correct way to report this, please correct me if I should report in another way. I found an old conversation between Leonardo and Florian about the Fatail internal error 200111022. The thread concluded that they could not reproduce the error. I got this error while converting a large project from Delphi to FPC. It turns out that a base class has a property Count, and a derived class has a function with the same name Count. This will compile, untill you call the property or function Count. I created an example that should explain it. Uncomment the marked line to get the fatal internal error: program project1; {$mode objfpc}{$H+} uses {$IFDEF UNIX}{$IFDEF UseCThreads} cthreads, {$ENDIF}{$ENDIF} Classes; type TBase = class private function GetCount: Integer; public property Count: Integer read GetCount; end; TSub = class(TBase) public function Count: Integer; overload; end; function TSub.Count: Integer; begin Result := 0; end; { TBase } function TBase.GetCount: Integer; begin Result := 0; end; var MySub: TSub; i : Integer; begin MySub := TSub.Create; // uncomment the next line for Fatal Internal error 200111022: // for i := 0 to MySub.Count do begin end; end. _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Birger Jansen
to Michael Van Canneyt

Hi Michael,

Yes, TSub.Count should be used. I agree that it is dirty and confusing. Best would be to only have it work in Delphi mode.

Kind regards,
Birger

-----Oorspronkelijk bericht-----
Van: Michael Van Canneyt
Verzonden: wo 20-10-2010 13:22
Aan: FPC developers' list ;
Onderwerp: Re: [fpc-devel] Fatal: Internal error 200111022

Show quoted text 79 lines
Hello, Which 'Count' should the compiler select ? I suspect TSub.Count ? I think we should prohibit this dubious construct in ObjFC mode. (but try to be delphi compatible in Delphi mode) Michael. On Wed, 20 Oct 2010, Birger Jansen wrote: > I'm not sure if this is the correct way to report this, please correct me if I should report in another way. > > I found an old conversation between Leonardo and Florian about the Fatail internal error 200111022. The thread concluded that they could not reproduce the error. > > I got this error while converting a large project from Delphi to FPC. It turns out that a base class has a property Count, and a derived class has a function with the same name Count. This will compile, untill you call the property or function Count. > > I created an example that should explain it. Uncomment the marked line to get the fatal internal error: > > program project1; > > {$mode objfpc}{$H+} > > uses > {$IFDEF UNIX}{$IFDEF UseCThreads} > cthreads, > {$ENDIF}{$ENDIF} > Classes; > > type > > TBase = class > private > function GetCount: Integer; > public > property Count: Integer read GetCount; > end; > > TSub = class(TBase) > public > function Count: Integer; overload; > end; > > function TSub.Count: Integer; > begin > Result := 0; > end; > > { TBase } > > function TBase.GetCount: Integer; > begin > Result := 0; > end; > > var > MySub: TSub; > i : Integer; > begin > MySub := TSub.Create; > // uncomment the next line for Fatal Internal error 200111022: > // for i := 0 to MySub.Count do begin end; > end. > _______________________________________________ > fpc-devel maillist - > http://lists.freepascal.org/mailman/listinfo/fpc-devel > _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Michael Van Canneyt
to Birger Jansen
Birger Jansen wrote
Hi Michael, Yes, TSub.Count should be used. I agree that it is dirty and confusing. Best would be to only have it work in Delphi mode.

Hi,

Can you please enter a bug-report for this, and simply mention these facts ?
- Fix as suggested in Delphi mode
- Prohibit in ObjFPC mode ?

So it won't be forgotten.

Michael.

Show quoted text 94 lines
Kind regards, Birger -----Oorspronkelijk bericht----- Van: Michael Van Canneyt Verzonden: wo 20-10-2010 13:22 Aan: FPC developers' list ; Onderwerp: Re: [fpc-devel] Fatal: Internal error 200111022 > > Hello, > > Which 'Count' should the compiler select ? I suspect TSub.Count ? > > I think we should prohibit this dubious construct in ObjFC mode. > (but try to be delphi compatible in Delphi mode) > > Michael. > > On Wed, 20 Oct 2010, Birger Jansen wrote: > >> I'm not sure if this is the correct way to report this, please correct me if > I should report in another way. >> >> I found an old conversation between Leonardo and Florian about the Fatail > internal error 200111022. The thread concluded that they could not reproduce > the error. >> >> I got this error while converting a large project from Delphi to FPC. It > turns out that a base class has a property Count, and a derived class has a > function with the same name Count. This will compile, untill you call the > property or function Count. >> >> I created an example that should explain it. Uncomment the marked line to get > the fatal internal error: >> >> program project1; >> >> {$mode objfpc}{$H+} >> >> uses >> {$IFDEF UNIX}{$IFDEF UseCThreads} >> cthreads, >> {$ENDIF}{$ENDIF} >> Classes; >> >> type >> >> TBase = class >> private >> function GetCount: Integer; >> public >> property Count: Integer read GetCount; >> end; >> >> TSub = class(TBase) >> public >> function Count: Integer; overload; >> end; >> >> function TSub.Count: Integer; >> begin >> Result := 0; >> end; >> >> { TBase } >> >> function TBase.GetCount: Integer; >> begin >> Result := 0; >> end; >> >> var >> MySub: TSub; >> i : Integer; >> begin >> MySub := TSub.Create; >> // uncomment the next line for Fatal Internal error 200111022: >> // for i := 0 to MySub.Count do begin end; >> end. >> _______________________________________________ >> fpc-devel maillist - >> http://lists.freepascal.org/mailman/listinfo/fpc-devel >> > _______________________________________________ > fpc-devel maillist - > http://lists.freepascal.org/mailman/listinfo/fpc-devel > _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Jonas Maebe
to Jonas Maebe
Jonas Maebe wrote 10 lines
On 20 Oct 2010, at 13:37, Michael Van Canneyt wrote: > Can you please enter a bug-report for this, and simply mention these facts ? > - Fix as suggested in Delphi mode > - Prohibit in ObjFPC mode ? Prohibiting it breaks the compilation of dom_html.pp: dom_html.pp(66,14) Error: Duplicate identifier "ClassName"

And some more:

fpgtkext.pp(78,14) Error: Duplicate identifier "UpdatePolicy"
fpgtkext.pp(78,14) Hint: Identifier already defined in unit FPGTK at line 1276
ltelnet.pp(143,14) Error: Duplicate identifier "SocketClass"
ltelnet.pp(143,14) Hint: Identifier already defined in unit LNET at line 214
lftp.pp(97,14) Error: Duplicate identifier "SocketClass"
lftp.pp(97,14) Hint: Identifier already defined in unit LNET at line 214

Jonas

Reply by email

Sergei Gorelkin
to Jonas Maebe: Prohibiting it breaks the compilation of dom_html.pp: dom_html.pp(66,14) Error: Duplicate…

Jonas Maebe пишет:

Show quoted text 10 lines
On 20 Oct 2010, at 13:37, Michael Van Canneyt wrote: > Can you please enter a bug-report for this, and simply mention these facts ? > - Fix as suggested in Delphi mode > - Prohibit in ObjFPC mode ? Prohibiting it breaks the compilation of dom_html.pp: dom_html.pp(66,14) Error: Duplicate identifier "ClassName"

If dom_html is the only problem, I think it can be fixed (by renaming ClassName). The w3.org specs has many property names which clash with Pascal reserved words (type, label, etc. That 'ClassName' was intended to be 'Class'.), so it's anyway impossible to follow the specs closely.

Regards,
Sergei

Reply by email

Jonas Maebe
to Sergei Gorelkin
Sergei Gorelkin wrote 6 lines
Jonas Maebe пишет: > Prohibiting it breaks the compilation of dom_html.pp: > dom_html.pp(66,14) Error: Duplicate identifier "ClassName" If dom_html is the only problem, I think it can be fixed (by renaming ClassName). The w3.org specs has many property names which clash with Pascal reserved words (type, label, etc. That 'ClassName' was intended to be 'Class'.), so it's anyway impossible to follow the specs closely.

Other than the ones from my second mail, Lazarus also has problems:

comctrls.pp(930,14) Error: Duplicate identifier "Owner"
comctrls.pp(930,14) Hint: Identifier already defined in unit CLASSES at line 497

(and probably more, since the compilation doesn't get further).

I guess it's more realistic to allow it in all modes.

Jonas

Reply by email

Sven Barth
to Jonas Maebe
Jonas Maebe wrote 18 lines
On 20 Oct 2010, at 15:12, Sergei Gorelkin wrote: > Jonas Maebe пишет: >> Prohibiting it breaks the compilation of dom_html.pp: >> dom_html.pp(66,14) Error: Duplicate identifier "ClassName" > If dom_html is the only problem, I think it can be fixed (by renaming ClassName). The w3.org specs > has many property names which clash with Pascal reserved words (type, label, etc. That 'ClassName' > was intended to be 'Class'.), so it's anyway impossible to follow the specs closely. Other than the ones from my second mail, Lazarus also has problems: comctrls.pp(930,14) Error: Duplicate identifier "Owner" comctrls.pp(930,14) Hint: Identifier already defined in unit CLASSES at line 497 (and probably more, since the compilation doesn't get further). I guess it's more realistic to allow it in all modes.

I don't know how others or the devs see that, but in my opinion its a very confusing possibilty to be able to redeclare e.g. "ClassName" (I shivered heavily when I read that). Like it's also confusing to have local variables in methods named like members of that class (which is forbidden in objfpc as well as you all might know).

All these cases should be fixed (although that might break further code), but its for some greater good (less confusion for new users of such a class). Until the release after 2.4.2 all code will be fixed hopefully (what about adding a warning to 2.4.2 for such cases?).

Regards,
Sven

Reply by email

Michael Van Canneyt
to Sven Barth
Sven Barth wrote 34 lines
On 20.10.2010 15:33, Jonas Maebe wrote: > > On 20 Oct 2010, at 15:12, Sergei Gorelkin wrote: > >> Jonas Maebe пишет: >>> Prohibiting it breaks the compilation of dom_html.pp: >>> dom_html.pp(66,14) Error: Duplicate identifier "ClassName" >> If dom_html is the only problem, I think it can be fixed (by renaming >> ClassName). The w3.org specs >> has many property names which clash with Pascal reserved words (type, >> label, etc. That 'ClassName' >> was intended to be 'Class'.), so it's anyway impossible to follow the >> specs closely. > > Other than the ones from my second mail, Lazarus also has problems: > > comctrls.pp(930,14) Error: Duplicate identifier "Owner" > comctrls.pp(930,14) Hint: Identifier already defined in unit CLASSES at > line 497 > > (and probably more, since the compilation doesn't get further). > > I guess it's more realistic to allow it in all modes. I don't know how others or the devs see that, but in my opinion its a very confusing possibilty to be able to redeclare e.g. "ClassName" (I shivered heavily when I read that). Like it's also confusing to have local variables in methods named like members of that class (which is forbidden in objfpc as well as you all might know). All these cases should be fixed (although that might break further code), but its for some greater good (less confusion for new users of such a class). Until the release after 2.4.2 all code will be fixed hopefully (what about adding a warning to 2.4.2 for such cases?).

If prohibiting (my preferred option) would cause too much breakage, I would also think that a warning is the least we can do.

I'm sure that the ComCtrls case above is a very dubious case indeed, I see very little reason to override TComponents 'Owner'.

Michael.

Reply by email