[lazarus] Lazarus ansistring AV?

[Marco van de Voort]

> I am not sure, but maybe this is related. 
> 
> Since the beginning of July the listbox test program stopped
> working. I didn't have time to investigate further.

Neli and I debugged it a bit, and it seems to be an ansistring
initialisation problem. 

Maybe it is, maybe not (only Neli had the AV, I didn't, he'll research it
more deeply later), but the problem we did find was a problem anyway, so I'd
like to warn for it.

The problem is near win32callback.inc:148 (version 1.41)

var LMessage : TLMessage;

 With PLMInsertText(@LMessage)^ Do
  Begin
   [..]
    Newtext:=string(lparam);
   [..]
  end;

There are at least one, and possible _two_ bugs in this single line.

First, because of the construct with the pointer and the @ in the WITH
clause, newtext isn't initialised to zero (as ansistrings should)

The declaration of LMessage should do that, but "TLMessage" doesn't contain
the ansistring field, so it is not initialised to zero. When nextext is
used, it is decreased in ref count, and since the random value points into
deep space, so accessing the ref count via the pointer can produce an AV.

It can be remedied by initing newtest to zero:

integer(newtext):=0;		// pchar(newtext):=nil isn't allowed.

The second problem is if you think what the assignment means:

newtext:=string(lparam);

With newtext=ansistring (which is a pointer type), and lparam is of type
longint (or integer) it says:

"type cast the integer value of lparam to a pointer. Store that pointer
in the place "newtext"

This while "lparam" is a pchar, IOW the pchar to ansistring conversion
doesn't take place.

So the correct typecast is:

newtext:=pchar(lparam);

Which says. "Lparam" is actually of type pchar, and assignment to an
ansistring will trigger proper conversion.

But in general I'd advise to keep such structures (as in lmessage etc)
pchar only, to avoid both problems a bit.

You can still assign the pchars to local "ansistring" variables.