(Android) Fehler in DateUtils behoben // TTimezone.Local.ID // Ich bitte um Prüfung

[himitsu]

Zitat:

Delphi-Quellcode:

Result.FName := Trim(TEncoding.UTF8.GetString(LChars));
Result.FName := Utf8ToString(LChars);

OK, abgesehn vom TRIM sollte, UTF8.GetString und Utf8ToString doch eigentlich gleiche Ergebnisse liefern,
und wenn sie das nicht tun, dann sollte man besser auch gleich mit prüfen was dort schief läuft.


Ansonsten:

Warum gibt die Funktion einen Pointer zurück, anstatt des Records?
Gerade hier ist das eine Liebslingsstelle für Speicherlecks und dazumal es absolot sinnlos ist, weil immer was zurückgegeben wird im Delphi (XE) ist/war das auch noch ein Record.

Und an ein paar gewissen Stellen würde ich noch eine Bereichsprüfung einfügen.

Zitat:

ExpDayOfWeek := CReDoW[ADoW];

entweder die {$RANGECHECKS ON} aktiv,
oder mit Fehlermelduing if ADoW > 6 then raise ...
oder zumindestens wildlaufende Speicherzugriffe abfangen ExpDayOfWeek := CReDoW[ADoW mod 7]; , was hier möglich ist, also einfach den Überstand in die nachfolgenden Wochen verschieben.

Und sonst erstmal noch nicht weiter gesucht. (war so das "Schlimmste", was gleich auf den ersten Blick brutal ins Auge stach)

[QuickAndDirty]

@himitsu
Ich habe wirklich nur 3 Zeilen in dem Listing verändert. "Korrektur" steht neben dran. Der rest ist original code aus dateutils.pas.
Ich habe quasi in der Funktion aus der Dateutils.pas einfach 3 stellen gepatcht.
Ich wollte möglichst wenig EmbarcaderoCode anfassen um mein Problem zu lösen.

@Rollo62
Ich habe jetzt mal die Funktion angesehen die den Fehler macht.
Liegst in der "System.pas"
Leider bin ich nicht gut bewandert in "codierung". Ich bin darauf angewiesen das die Convertierungsmethoden funktionieren.
UTF8ToUnicode gibt es in etlichen überladenen methoden...


unit System.pas

Delphi-Quellcode:

function UTF8ToString(const S: array of Byte): string; overload;
var
  Dest: array[0..511] of Char;
begin
  SetString(Result, Dest, UTF8ToUnicode(Dest, Length(Dest), _PAnsiChr(@S[1]), S[0])-1);
end;

{$IFDEF USE_LIBICU}
{$IFDEF LINUX}
function Utf8ToUnicodeICU(Dest: PWideChar; MaxDestChars: Cardinal; Source: _PAnsiChr; SourceBytes: Cardinal): Cardinal;
{$ELSE !LINUX}
function Utf8ToUnicode(Dest: PWideChar; MaxDestChars: Cardinal; Source: _PAnsiChr; SourceBytes: Cardinal): Cardinal;
{$ENDIF LINUX}
var
  DestLen: Int32;
  ErrorConv: UErrorCode;
begin
  Result := 0;
  if Source = nil then Exit;
  ErrorConv := 0;
  DestLen := 0;
  u_strFromUTF8(PUChar(Dest), MaxDestChars, DestLen, MarshaledAString(Source), SourceBytes, ErrorConv);
  Result := DestLen;
  if Dest <> nil then
  begin
    if (Result > 0) and (Result <= MaxDestChars) then
    begin
      if Result = MaxDestChars then
      begin
        if (Result > 1) and (Word(Dest[Result - 1]) >= $DC00) and (Word(Dest[Result - 1]) <= $DFFF) then
          Dec(Result);
      end else
        Inc(Result);
      Dest[Result - 1] := #0;
    end;
  end;
end;

Edit:
!!!!!!!!!!!!!!HOLY COW!!!!!!!!!!

Delphi-Quellcode:

function UTF8ToString(const S: array of Byte): string; overload;
var
  Dest: array[0..511] of Char;
begin
  SetString(Result, Dest, UTF8ToUnicode(Dest, Length(Dest), _PAnsiChr(@S[1]), S[0])-1);      //   _PAnsiChr(@S[1]) ist "ET"  _PAnsiChr(@S[0]) müsste dann "CET" sein???
end;

[QuickAndDirty]

OK, Was nun???

[himitsu]

Nun: Bugmeldung im Quality-Portal

S[Low(string)] statt S[1]
oder gleich den Mist mit dem @ lassen, also PAnsiChr(S) statt PAnsiChr(@S[1]) .

Grund: $ZeroBasedStrings sind im NextGen (Android/iOS) aktiv.
http://docwiki.embarcadero.com/RADSt...rings_(Delphi)

[Rollo62]

Nur mal gerade in den Delphi-Sourcen gesucht, es gibt allein ca. 34-40 Units die das benutzen.
Das würde ja an allen möglichen Stellen abrauchen, kann ich gar nicht glauben
Ganz zu schweigen von externen Libraries und Code.
Macht Emba keine Unit-Tests ?

Was ist jetzt besser, nur bei DateUtils zu fixen oder direkt das Übel an der Wurzel ? Gute Frage.

Ich muss wohl mal bei mir checken ob und wo ich das nutze.

[himitsu]

Besser ist es immer das grundlegende Problem, anstatt nur die Symptome zu beheben.
Rein funktionell geht es auch den "Fehler" an beiden Stellen zu beheben, wobei TEncoding da einen größeren Overhead hat.


Wenn du über den String-Helper gehst, dann ist es dort auch überall 0-basiered und in jeder Platform einheitlich.
S.Chars(0) = S[1] {im Windows} ... abgesehn von dem nutzlosen Funktionsaufruf bei .Chars .

Auch beim Copy-Befehl seh ich zu oft, dass es bei 0 beginnt (Copy(S, 0, ...) ), was "oft" funktioniert, da es nach unten abgefangen wird, aber mit höheren Indize wird dann natürlich auch falsch zugegriffen, wenn der Entwickler das immer falsch macht.

[QuickAndDirty]

Zitat von Rollo62:

Nur mal gerade in den Delphi-Sourcen gesucht, es gibt allein ca. 34-40 Units die das benutzen.
Das würde ja an allen möglichen Stellen abrauchen, kann ich gar nicht glauben
Ganz zu schweigen von externen Libraries und Code.
Macht Emba keine Unit-Tests ?

Es gibt das in vielen (5?) überladenen versionen.
Sprich vielleicht kommt bei dir nie die Array of Bytes version zum Einsatz...
Überladene namen lassen sich leider nicht wirklich toll suchen!

Zitat von Rollo62:

Was ist jetzt besser, nur bei DateUtils zu fixen oder direkt das Übel an der Wurzel ?

Ja, eben. Was nun?

Zitat von Rollo62:

Gute Frage.

Deine Frage war übrigens auch nicht übel.

[QuickAndDirty]

Zitat von himitsu:

Nun: Bugmeldung im Quality-Portal

S[Low(string)] statt S[1]
oder gleich den Mist mit dem @ lassen, also PAnsiChr(S) statt PAnsiChr(@S[1]) .

Grund: $ZeroBasedStrings sind im NextGen (Android/iOS) aktiv.
http://docwiki.embarcadero.com/RADSt...rings_(Delphi)

Meinst du so

Delphi-Quellcode:

function UTF8ToString(const S: array of Byte): string; overload;
var
  Dest: array[0..511] of Char;
begin
  // _PAnsiChr(@S[1]) ist "ET" _PAnsiChr(@S[0]) müsste dann "CET" sein???
  // SetString(Result, Dest, UTF8ToUnicode(Dest, Length(Dest), _PAnsiChr(@S[1]), S[0])-1); 
  SetString(Result, Dest, UTF8ToUnicode(Dest, Length(Dest), PAnsiChr(S), length(S))-1); 
  //
end;

und was bedeutet in
UTF8ToUnicode(a, b, c, d) -1 das "-1"
????

[samso]

Zitat von QuickAndDirty:

Delphi-Quellcode:

function UTF8ToString(const S: array of Byte): string; overload;
var
  Dest: array[0..511] of Char;
begin
  SetString(Result, Dest, UTF8ToUnicode(Dest, Length(Dest), _PAnsiChr(@S[1]), S[0])-1);      //   _PAnsiChr(@S[1]) ist "ET"  _PAnsiChr(@S[0]) müsste dann "CET" sein???
end;

Diese Funktion ist anscheinend von ShortString nach "array of bytes" adaptiert worden. Man beachte das S[0]. Das soll ja wohl die Länge sein..

[QuickAndDirty]

Zitat von samso:

Zitat von QuickAndDirty:

Delphi-Quellcode:

function UTF8ToString(const S: array of Byte): string; overload;
var
  Dest: array[0..511] of Char;
begin
  SetString(Result, Dest, UTF8ToUnicode(Dest, Length(Dest), _PAnsiChr(@S[1]), S[0])-1);      //   _PAnsiChr(@S[1]) ist "ET"  _PAnsiChr(@S[0]) müsste dann "CET" sein???
end;

Diese Funktion ist anscheinend von ShortString nach "array of bytes" adaptiert worden. Man beachte das S[0]. Das soll ja wohl die Länge sein..

Das denke ich auch. Und die Funkionen ein paar Zeilen darüber muten auch alle wie ein Copy-Pasta aus einer Shortstring Funktion an....
Ich habe einfach nur Angst dass in System.pas zu beheben.... wegen der Abhängigkeiten... vielleicht erwartet Abhängigercode diesen Fehler und trägt dafür Sorge...