Hi,

Do I create a memory leak if I cast a PChar it a AnsiString. Then append text to the AnsiString and then cast it back to the original PChar?

eg:
var
Text: Pchar; <-- global var containing text.

procedure AppendText(const AText: string);
var
  s: string;
begin
  s := Text + AText;
  Text := PChar(s);
end;

I'm busy converting a old program from OS/2 days that used PChar exensively. I'm slowly but surely converting this code to AnsiString. But as a quick fix, am I allowed to do what is shown above? Without causing memory leaks or something else?

No, you don't create memory leak. But your code neither works, because s is local to AppendText, and PChar(s) becomes void after call to AppendText - memory used by s will be deallocated, and since PChar(s) = @s[1] Text would be invalid pointer. You will either need to convert Text to SomeString, or do manual (de)allocation.

The reason why I'm not sure, is because I created a simple console test application. Initially, running the program, I got the correct output. Then I thought I would enable 'heaptrc' (-gh compiler parameter) to make sure I am not leaking memory in the application. Now with heaptrc enabled, I get some strange output.. :-(

So now I'm confused.

---- with heaptrc enabled------------------------
$ ./project1
t=hello
Text=hello
Text=������������ﾭ
Heap dump by heaptrc unit
20 memory blocks allocated : 608/632
20 memory blocks freed : 608/632
0 unfreed memory blocks : 0
True heap size : 131072
True free heap : 131072

---- Without heaptrc enabled------------------------ tmp $ ./project1
t=hello
Text=hello
Text=hello world

I'm using FPC 2.3.1 (latest revision) using 64bit Linux.

I don't think a memory leak. But a problem yes.

Text will have random content afterwards!

s := Text + AText;

"s" will be the new string. => new memory allocated

Text := PChar(s);

"Text" will be a pointer to the memory allocet by "s"

At the end of the procedure "s" will be freed (because it's a local string, so it has no longer any references)
"Text" will then point to unallocated memory (still holding the string) => but as soon as your program does anything, the memory may be reused, and "text" points to random data.

If PChar points to a string, then the strig must be kept as long as pchar is used. (I run into that issue myself, last year....)

Martin

ok

Text := PChar(s);

wrong, because the local s is the only one having increased the ref count ...

end;

... therefore the 'end' will free the ansistring.

BTW 'text' is a system type.

I'm busy converting a old program from OS/2 days that used PChar exensively. I'm slowly but surely converting this code to AnsiString. But as a quick fix, am I allowed to do what is shown above? Without causing memory leaks or something else?

Mattias

Crap, I forgot to explain the output.

 t: string;
 Text: PChar

The last line is the result of Text after AppendText() was called. AppendText() is defined like in my first posting.

2009/10/29 Graeme Geldenhuys :

This will only work if you make s global, too...

Henry

I guess heaptrc expose that you are looking at memory that is already freed.

Vincent

Text points to garbage after AppendText() because s will be freed at end of AppendText().

Martin

Text:=strnew(PChar(s));

end;

Mattias

2009/10/29 Mattias Gaertner :

Won't this leak? You'll have to initialise text to null, then use strdispose before strnew if text is not null.

Henry

Right you are.
I hit the sent button too early.

Mattias

Mattias Gaertner wrote

Text:=strnew(PChar(s));

You read my mind. I was going to ask if it's ok to cast a PString to a PChar.

Trying what you suggested, I get the following compiler error.

project1.lpr(20,11) Error: Incompatible types: got "PString" expected "PChar"

Changing my test code to the following solves the compiler error, but now heaptrc reports that I have two memory leaks.

--------------------------
var
  Text: PChar;
procedure AppendText(const AText: string);
var
  s: string;
begin
  s := Text + AText;
  StrDispose(Text);
  Text := PChar(NewStr(s));
end;
var
  t: string;
begin
  t := 'hello';
  writeln('t=', t);
  Text := PChar(t);
  writeln('Text=', Text);
  AppendText(' world');
  writeln('Text=', Text);
end.
---------------------------

And the console output:

$ ./project1
t=hello
Text=hello
Text=P8
Heap dump by heaptrc unit
21 memory blocks allocated : 616/640
19 memory blocks freed : 580/600
2 unfreed memory blocks : 36
True heap size : 131072
True free heap : 130720
Should be : 130776
Call trace for block $00007F42BFFFB3E0 size 8
$0000000000400366 line 30 of project1.lpr
$0000000000400178
Call trace for block $00007F42C0003840 size 28
$0000000000400366 line 30 of project1.lpr
$0000000000400178

Line 30 being the call to AppendText()

Yes.
But it will not change the reference count.

Trying what you suggested, I get the following compiler error. project1.lpr(20,11) Error: Incompatible types: got "PString" expected "PChar"

It compiles here. Probably you use some special units.

ok
Not very fast, but ok.

Graeme, why don't you just change the type of 'Text' to string?

This does not change the reference count:
Text := PChar(t);
The string is not duplicated. And StrDispose can not free that. And 'Text' is not freed at the end.

Mattias

2009/10/29 Graeme Geldenhuys :

This is probably dependant on compiler modes?

You may have to do it like this:

StrDispose(Text);
Text := StrAlloc(length(s) + 1);
StrPCopy(Text, s);

Henry

2009/10/29 Henry Vermaak :

This is probably dependant on compiler modes?

I'm using: $mode objfpc

Ah, now it works plus no memory leaks.
Thanks! :-)

Wow, something as simple as concatenating string and end up being so complex. Poor C programmers that have to constantly work with pointers and null terminated strings. ;-)

2009/10/29 Mattias Gaertner :

It compiles here. Probably you use some special units.

Weird... As I mentioned, I'm using FPC 2.3.1 (64bit) under Linux and $mode objfpc.

Graeme, why don't you just change the type of 'Text' to string?

That's the plan - eventually. But the code is large and PChar is passed around all over the place. So changing that one field to String type has a snowball effect on parameter types etc... Something I don't have time for right now. But yes, I eventually want to change all the PChar's to String type. I already replace the PString types with standard String.

I hope you mean {$mode objfpc}{$H+}

Mattias

2009/10/29 Mattias Gaertner :

I hope you mean {$mode objfpc}{$H+}

:-) Yes.

In our previous episode, Henry Vermaak said:

No, probably mixed sysutils and strings(?) use. pstring is defined in both TP and Delphi. Once to short, once to ansistring

Marco van de Voort wrote

No, probably mixed sysutils and strings(?) use. pstring is defined in both TP and Delphi. Once to short, once to ansistring

That that must be FPC that is getting confused. In Lazurus I when "Project > New > Free Pascal application". That's as basic as you can get. The uses clause only had Classes and SysUtils in it. No TCustomApplication descendant or nothing, just a plain begin.... end. in the project file with the code I posted before.