Code mit AnsiString lief unter 10.0 Seattle, crasht unter 10.4 Sydney

[samso]

Zitat von himitsu:

dann dreht wohl der Compiler durch.

Das befürchte ich auch. Wie sieht die Funktion _LStrToPChar bei Sydney denn aus? Bei dem alten Delphi ist es im wesentlichen ein Cast:

Delphi-Quellcode:

function _LStrToPChar(const S: _AnsiStr): _PAnsiChr;
begin
  if Pointer(s) = nil then
    Result := @(PEmptyString(@EmptyStringA[1])^.Nul)
  else
    Result := Pointer(s);
end;

Bzw. wird bei PAnsiChar(asAnsi) immer noch _LStrToPChar aufgerufen?

[hannsg]

Hallo,

ohne mich durch die Details gearbeitet zu haben: Hr. Eißing hat im Webinar zu 10.4 erwähnt, dass sich die default-Einstellung von $ZEROBASEDSTRINGS in 10.4 geändert hat. Vielleicht hat es etwas damit zu tun?

Schöne Grüße,
Meik

[Der schöne Günther]

Ich glaube das betrifft nur die iOS und Android-Compiler, oder?

Es muss ja irgend etwas mit der Referenzzählung des Strings sein, denn durch Einführen einer zusätzlichen Variable funktioniert es ja wieder.

[samso]

Zitat von Der schöne Günther:

Es muss ja irgend etwas mit der Referenzzählung des Strings sein, denn durch Einführen einer zusätzlichen Variable funktioniert es ja wieder.

Deshalb ja meine Frage in #7.

Bei dem Aufruf MapAndLoad(PAnsiChar(asAnsi)... wird implizit _LStrToPChar aufgerufen. Wenn Du über die zusätzlichen Variable mit asPAnsiChar := Addr(asAnsi[1]); gehst, dann wird _LStrToPChar nicht benutzt.

Ich vermute, wenn Du statt

asPAnsiChar := Addr(asAnsi[1]); wieder

asPAnsiChar := PAnsiChar(asAnsi); benutzen würdest, kracht es wieder. Denn dann wird wieder _LStrToPChar aufgerufen. Das würde dann zeigen, dass es nicht an der zusätzlichen Variablen liegt, sondern am Aufruf von _LStrToPChar.

[Der schöne Günther]

Ah danke, jetzt habe sogar ich das verstanden. Und ja, unter 10.4 Sydney sieht es nun anders aus:

Delphi-Quellcode:

function _LStrToPChar(const S: _AnsiStr): _PAnsiChr;
begin
  if Pointer(s) = nil then
    Result := @(PEmptyString(Pointer(EmptyStringA))^.Nul)
  else
    Result := Pointer(s);
end;

Vorher (laut dir):

Delphi-Quellcode:

function _LStrToPChar(const S: _AnsiStr): _PAnsiChr;
begin
  if Pointer(s) = nil then
    Result := @(PEmptyString(@EmptyStringA[1])^.Nul)
  else
    Result := Pointer(s);
end;

Aus @EmptyStringA[1] wurde Pointer(EmptyStringA) . Vielen Dank. Ich konnte nichts finden weshalb das geändert worden ist. Außerdem spielen leere Strings hier ja keine Rolle. Wahrscheinlich hat sich noch mehr geändert.

PS: Unter 64 Bit funktioniert alles weiterhin wie gehabt. Wahrscheinlich steckt irgendwo ein Fehler in diesem mystischen Assemblercode.

PPS: Ich habe mal einen neuen Eintrag angelegt unter
https://quality.embarcadero.com/browse/RSP-29567

[jaenicke]

Ich kann das leider nicht reproduzieren. Ich habe es einmal mit GetTimeUTC(Application.ExeName) versucht. Hättest du einmal ein komplettes Beispiel mit dem Aufruf? Das würde ich bei einer Bugmeldung dringend empfehlen: Genau schreiben wie es reproduzierbar ist, wenn irgendwie möglich. Ansonsten wird dein Jira-Eintrag vermutlich als nicht reproduzierbar geschlossen...

[Der schöne Günther]

Ja, du hast Recht. Das Merkwürdige: var dateTime := GetTimeUTC( ParamStr(0) ) liefert bei mir auch keinen Fehler. Nehme ich aber stattdessen var timestamp := DateTimeToStr( GetTimeUTC( ParamStr(0) ) ); kommt es zur AV. Allerspätestens hier endet mein Verständnis. Jetzt müssen die Profis ran.

Ich habe dem Report eine komplette .DPR angehangen (Direktlink)

[samso]

Zitat von Der schöne Günther:

Ah danke, jetzt habe sogar ich das verstanden. Und ja, unter 10.4 Sydney sieht es nun anders aus.

Aus @EmptyStringA[1] wurde Pointer(EmptyStringA) . Vielen Dank. Ich konnte nichts finden weshalb das geändert worden ist. Außerdem spielen leere Strings hier ja keine Rolle. Wahrscheinlich hat sich noch mehr geändert.

Danke! Diese Änderung ist ja eher kosmetischer Natur. @EmptyStringA[1] und Pointer(EmptyStringA) erzeugt - solange die Strings nicht Zerobased sind - ja exakt den gleichen Assemblercode. Damit ist diese Fehlermöglichkeit raus.

[Der schöne Günther]

Die Ursache war übrigens eine ganz andere: Die Definition von TLoadedImage ist in 10.4 falsch, was dann dazu führte dass in den Bereich vom AnsiString reingeschrieben wurde.

(https://quality.embarcadero.com/browse/RSP-29567)