PChar als Result wird verfälscht

[Stevie]

Hallo Leute,

ich bin gerade dabei, einen Bug in Zeos zu beheben, aber ich komm nicht drauf.
Ich habe folgende Funktion:

Delphi-Quellcode:

function TZRowAccessor.GetPChar(ColumnIndex: Integer;
  var IsNull: Boolean): PChar;
begin
{$IFNDEF DISABLE_CHECKING}
  CheckColumnConvertion(ColumnIndex, stString);
{$ENDIF}
  Result := nil;
  if FBuffer.Columns[FColumnOffsets[ColumnIndex - 1]] = 0 then
  begin
    case FColumnTypes[ColumnIndex - 1] of
      stString:
        Result := @FBuffer.Columns[FColumnOffsets[ColumnIndex - 1] + 1];
      else
        Result := PChar(GetString(ColumnIndex, IsNull)); // <-- diese Zeile wird ausgeführt
    end;
    IsNull := False; // <-- Haltepunkt
  end else
    IsNull := True;
end;

Beim Haltepunkt steht das richtige Ergebnis in Result,
allerdings werden beim nächsten Befehl einige Zeichen abgeschnitten/verfälscht.

Im CPU-Fenster kann ich beobachten, dass der Aufruf der Methode LStrClr diese Veränderung hervorruft.
Das komische ist, dass dies unregelmäßig geschieht. Hat jemand eine Ahnung, woran das liegen könnte?

MfG
Stevie

[Robert Marquardt]

Ein String in Delphi hat einen Referenzzaehler. Temporaere Strings wie der von GetString werden gleich wieder geloescht, da PChar() natuerlich nicht den Referenzzaehler erhoeht.
Der Zeiger zeigt also auf einen freigegebenen Speicherbereich, der natuerlich schnell wiederverwertet wird.

Der Fehler ist prinzipiell. ZRowAccessor.GetPChar ist unsinnig.

[Stevie]

Zitat von Robert Marquardt:

Ein String in Delphi hat einen Referenzzaehler. Temporaere Strings wie der von GetString werden gleich wieder geloescht, da PChar() natuerlich nicht den Referenzzaehler erhoeht.
Der Zeiger zeigt also auf einen freigegebenen Speicherbereich, der natuerlich schnell wiederverwertet wird.

Der Fehler ist prinzipiell. ZRowAccessor.GetPChar ist unsinnig.

Hrmpf Die Funktion ist so in Zeos fest eingebunden.

Gibt es eine Möglichkeit, dass dieser temporäre string nicht wieder freigegeben wird?

[Muetze1]

Moin!

Nutze die alten Funktionen wie StrAlloc() um die Speicher zu alloziieren und StrPCopy() um diesen zu befüllen.

MfG
Muetze1

[Stevie]

Ich hab mir jetzt mal anders beholfen und eine string-variable im privaten Bereich des Objekts angelegt,
wo ich das Ergebnis von GetString speichere. Dieses wird dann an die Funktion PChar übergeben.
Bis jetzt kann ich den Fehler nicht mehr feststellen. Könnte das die Lösung sein?

[Zacherl]

Hallo,
Also wenn der Fehler nicht mehr kommt, dürfte das Problem wohl erledigt sein, oder?

Florian

[Robert Marquardt]

Ja, das ist die Loesung. Jetzt ist der String gueltig solange es das Objekt gibt.
String ist bei Delphi die einzig wirklich vollstaendig objektorientiert Datentyp.
Bei einer lokalen Variablen wird z. B. heimlich ein try finally eingerichtet und die Variable erst auf nil = Leerstring initialisiert und im finally wieder freigegeben. Entsprechjhndes gilt natuerlich fuer Elemente einer Klasse.
Das ist auch der Grund warum eine Funktion mit string-Result nie ueber ein uninitialisiertes Ergebnis klagt. Result faellt namelich unter die lokalen Variablen und wird initialisiert (aber natuerlich nicht freigegeben).