Hi All,

I've just recently started using Free Pascal through the Lazarus project, and I've found a bit of my code which is causing problems with the compiler.

I've attached the complete sample program below. In objfpc mode everything works fine; in delphi mode the Length(c.IntArray[0]) line causes it to fail with an internal error 200405023. Also compiles if I first assign c.IntArray[0] to a variable and then ask for it's length.

I'm compiling using fpc 1.9.6, 2005/01/03, for i386, on Windows 2000.

Regards,
Craig Peterson

program project1;
{$mode delphi}
uses
   types;
type
   TTestClass = class
     function GetIntArray(Index: Integer): TIntegerDynArray;
     property IntArray[Index: Integer]: TIntegerDynArray
       read GetIntArray;
   end;
function TTestClass.GetIntArray(Index: Integer): TIntegerDynArray;
begin
   Result := nil;
end;
var
   c: TTestClass;
   x: Integer;
begin
   c := TTestClass.Create;
   x := Length(c.IntArray[0]);
end.

Already fixed in todays compiler.

Already fixed in todays compiler.

Hi all,

the bug-report on the website doesn't work, so I write a mail:

If you assign a widechar to a pwidechar, the refcount isn't increased. This construct is often used in the variants-code, which is allowed, according to the comments at the top of wstrings.inc.

An example:

Program test;
var PW    : PWideChar;
    dummy : AnsiString;
procedure Set_PW;
var
  W : WideString;
  s : ansistring;
begin
  s := 'Hello world'; // Can't assign directly to W, because that's
  W := s;             // interpreted as a constant with a refcount of -1
  PW := PWideChar(W); // <- Bug, refcount of W (and PW) isn't increased
end;                  // <- Memory at @W is deallocated, since refcount=0
begin
  Set_PW;
  SetLength(Dummy,3);   // The dummy is allocated at the same address as PW
  writeln(pchar(PW)[0]); // Should write 'H', but it doesn't
end.

JoJo,
Joost.

this is not a bug

if when someone does pcharvar := ansistringvar or pwidecharvar := widestringvar we increased the refcount every program that used that construct would leak memory.

where compiler automated types like ansistring and widestring meet non automated types like pchar and pwidechar some care is required on the part of the developer. If you don't like this move to a nanny state language like java.

if when someone does pcharvar := ansistringvar or pwidecharvar := widestringvar we increased the refcount every program that used that construct would leak memory.

Normally I would aggree with you, but as far as I can see, PWideChar is also an automated type. (If not then large parts of the variant-code in the RTL has to be rewritten, and probably alsoe the wstrings.inc file)

From wstrings.inc:

WideString is defined as a 'silent' pwidechar :
a pwidechar that points to :

  @-8  : SizeInt for reference count;
  @-4  : SizeInt for size;
  @    : String + Terminating #0;
  Pwidechar(Widestring) is a valid typecast.
  So WS[i] is converted to the address @WS+i-1.

So there is a bug somewhere. But if they should not be refcounted, that's ok. But then I have some fixs for the variant-code

Joost

Above is just an internal description of WideString layout in memory, so this layout allows easy type conversion of WideString to PWideChar. Note: PWideChar, PAnsiChar, PChar are just pointers and not garbage collected by compiler. But AnsiString and WideString are compiler managed types. So, as Peter mentioned, behaviour you are seeing is by design.

Kylix doesn't increase the refcount. Add the following line before and after the assignment to print the refcount:

  writeln(plongint(pchar(w)-8)^);

Kylix doesn't increase the refcount. Add the following line before and after the assignment to print the refcount:

  writeln(plongint(pchar(w)-8)^);

Kylix doesn't increase the refcount. Add the following line before and after the assignment to print the refcount:

  writeln(plongint(pchar(w)-8)^);

Alexey Barkovoy wrote

PAnsiChar, PChar are just pointers and not garbage collected by compiler. But AnsiString and WideString are compiler managed types. So, as Peter mentioned, behaviour you are seeing is by design.

In Delphi WideString is not reference layout of the string prefix is dictated by the Windows API (BSTR type), and AFAIK Windows also doesn't use reference counting with this type, or with OLEVariants containing wide strings.

DoDi

That is something Windows specific. For Kylix it is reference counted.

----- Original Message -----