TStringHelper 0-indiziert

[Incocnito]

Moin Zusammen,

ich brauche mal etwas seelischen Beistand ...
Ich habe eine (nicht nachstellbare) Zugriffsverletzung in einer Funktion gehabt, welche bei TStringHelper.Trim ausschlägt.
Jetzt schaue ich mir die Funktion an und stelle bei Delphi 10.4 fest, dass dort hard-coded mit
0-Indizierten Strings gearbeitet wird.
Wenn ich die Funktion kopiere und so an anderer Stelle aufrufe knallt es logischer Weise.

Beispiel:
Ich nehme den String sValue mit Wert "S" sage dann "Trim(S)" und er fliegt gleich mit Bereichsprüfungs-Fehlern raus,
da er versucht auf sValue[0] zuzugreifen.

Hier der Auszug aus System.SysUtils (in der Hoffnung, dass ich damit kein Copyright verletze!):

Delphi-Quellcode:

function TStringHelper.Trim: string;
var
  I, L: Integer;
begin
  L := Self.Length - 1;
  I := 0;
  if (L = -1) or (Self[I] > ' ') and (Self[L] > ' ') then Exit(Self);
  while (I <= L) and (Self[I] <= ' ') do Inc(I);
  if I > L then Exit('');
  while Self[L] <= ' ' do Dec(L);
  Result := Self.SubString(I, L - I + 1);
end;

Das gleiche passiert auch an anderen Stellen beim TStringHelper.

Wie kann das funktionieren? Weiß das jemand? Sieht die echte "TStringHelper.Trim"-Funktion anders aus?
Ich hätte erwartet, dass er entweder eine Unterscheidung für die Zielplattformen hat,
oder eine Korrektur fährt (ich nutze für String-Funktionen, welche für beides genutzt wird
zum Beispiel die Funktion "Low(sValue)", um jeweils den Startindex anzupassen, wenn ich das
nicht mit StringHelper-Funktionen umgehen kann und beispielsweise den String manuell durchlaufe.
Sorgen irgendwelche Compiler-Direktiven dafür, dass er das hintenrum irgendwie grade biegt,
oder hat da einfach nur jemand die Bereichsprüfung deaktiviert und das knallt nur aus Glück bei niemandem?

Liebe Grüße
Incocnito

[jaenicke]

Zitat:

Zitat von Incocnito (Beitrag 1536701)

Ich habe eine (nicht nachstellbare) Zugriffsverletzung in einer Funktion gehabt, welche bei TStringHelper.Trim ausschlägt.
[..]
Ich nehme den String sValue mit Wert "S" sage dann "Trim(S)" und er fliegt gleich mit Bereichsprüfungs-Fehlern raus,
da er versucht auf sValue[0] zuzugreifen

Was hat Trim(S) denn mit dem String-Helper zu tun?
Um den Helper zu verwenden, müsstest du S.Trim verwenden.

Konkreter Quelltext und die Fehlerdetails wären hilfreich.

// EDIT:
Ach ja, weshalb das funktioniert:
Dort wird mit der passenden Compilerdirektive gearbeitet.

Delphi-Quellcode:

{$ZEROBASEDSTRINGS ON}
// wie der Name schon sagt, kann man danach auf Index 0 zugreifen

[Uwe Raabe]

Zitat:

Zitat von Incocnito (Beitrag 1536701)

Sorgen irgendwelche Compiler-Direktiven dafür, dass er das hintenrum irgendwie grade biegt,

Exakt:

Delphi-Quellcode:

{$ZEROBASEDSTRINGS ON}

- steht auch so bei der TStringHelper Implementierung.

[Incocnito]

Zitat:

Zitat von jaenicke (Beitrag 1536702)

...Was hat Trim(S) denn mit dem String-Helper zu tun?
Um den Helper zu verwenden, müsstest du S.Trim verwenden....

Ja, hast ja Recht XD Ich hatte die Funktion umkopiert und dann halt keine String-Helper-Funktion mehr (weil ich den StringHelper ja nicht überschreiben wollte),
sondern nur eine "normale" Funktion gemacht, welche ich dann als "TrimX(sValue)" aufgerufen hatte.
Das hat jetzt in meinem Text für sprachliche Verwirrung gesorgt. :-S

Zitat:

Zitat von jaenicke (Beitrag 1536702)

Konkreter Quelltext und die Fehlerdetails wären hilfreich.

Der Fehler trat auf bei der Verwendung von IsNullOrWhiteSpace auf einem mir unbekanntem String.
Und ist innerhalb von "Trim" als Zugriffsverletzung aufgetreten.
Daher schaue ich gerade was das wohl für ein String (Leerstring? String mit nur einem Sonderzeichen?)
gewesen sein könnte. (Aktueller Stand: Das kann ja gar nicht!)

Zitat:

Zitat von jaenicke (Beitrag 1536702)

// EDIT:
Ach ja, weshalb das funktioniert:
Dort wird mit der passenden Compilerdirektive gearbeitet.

Delphi-Quellcode:

{$ZEROBASEDSTRINGS ON}
// wie der Name schon sagt, kann man danach auf Index 0 zugreifen

bzw.

Zitat:

Zitat von Uwe Raabe (Beitrag 1536703)

...
Exakt:

Delphi-Quellcode:

{$ZEROBASEDSTRINGS ON}

- steht auch so bei der TStringHelper Implementierung.

Ok, das ist für mich schon verrückte Compiler-Magie, da er ja offenichtlich auf dem selben Speicher (der selben String-Variable) mal
mit 0 indiziert und mal mit 1 indiziert arbeiten kann. Ich hatte diese Direktive eher als

Code:

ab hier sind alle Variablen vom Typ "String" tatsächlich vom Typ "AnsiRawUnicodeWhateverSuperSpezialString"

gelesen, aber dann würde das beim Funktionsaufruf ja nicht mehr klappen.
Auf jeden Fall euch beiden schonmal besten Dank für die "Erleuchtung". Jetzt kann ich wenigstens wieder ruhig schlafen. ;-)

Liebe Grüße
Incocnito