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

[QuickAndDirty]

Zitat:

Zitat von Rollo62 (Beitrag 1470021)

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 :shock:
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:

Zitat von Rollo62 (Beitrag 1470021)

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

Ja, eben. Was nun?

Zitat:

Zitat von Rollo62 (Beitrag 1470021)

Gute Frage.

Deine Frage war übrigens auch nicht übel. ;-)

[QuickAndDirty]

Zitat:

Zitat von himitsu (Beitrag 1470017)

Nun: Bugmeldung im Quality-Portal

Delphi-Quellcode:

S[Low(string)]

statt

Delphi-Quellcode:

S[1]

oder gleich den Mist mit dem @ lassen, also

Delphi-Quellcode:

PAnsiChr(S)

statt

Delphi-Quellcode:

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

Delphi-Quellcode:

UTF8ToUnicode(a, b, c, d) -1

das "-1"
????

[QuickAndDirty]

Zitat:

Zitat von samso (Beitrag 1470030)

Zitat:

Zitat von QuickAndDirty (Beitrag 1470004)

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...

[himitsu]

Zitat:

Zitat von QuickAndDirty (Beitrag 1470097)

vielleicht erwartet Abhängigercode diesen Fehler und trägt dafür Sorge...

Dann ist das ein Fehler in sich.

Diese Funktion ist definitiv falsch, also gehört sie gebugfixt.
Wenn anderer Code diesen "Fehler" erwartet und ungeprüft übernimmt, dann ist dort jemand selbst Schuld.


Wie das jetzt ganz genau am Besten gefixt werden sollte, da müsste ich auch nochmal genauer drüberschauen,
aber da man die System.pas sowieso nicht wirklich kompilieren/austauschen kann, ist es sowieso egal.
Eine alternative funktionierende Funktion mit TEncoding hast du ja und kannst (erstmal) was Anderes benutzen.

Ansonsten muß dieser Fehler (egal ob mit oder ohne Lösungsvorschlag) als "dringend" im Quality-Portal gemeldet werden.
quality.embarcadero.com
IMHO sollte Emba das auch mindestens für 10.3 und 10.4 schnellstmöglich als Patch rausgeben, denn ich würde das schon als "sehr schweren" Fehler betrachten, da diese Funktionen auch von Delphi selbst öfters benutzt werden.

[himitsu]

[edit]
please vote

https://quality.embarcadero.com/browse/RSP-10568
https://quality.embarcadero.com/browse/RSP-10581

Also eigentlich hätte man das schon längst beheben können. :wall:

[QuickAndDirty]

OK Ich werde dann mal meinem Chef sagen das er das upvoten soll...
Wie heist noch mal der user hier, der auch bei Embarcadero leute kennt?
Ist WANG WANG irgend eine wichtige Person? Weil er stellt sich in den threads echt etwas dumm an.
Warum ist RSP-10568 closed?

bis jetzt nur 9 votes für RSP-10581....

[himitsu]

Da steht es sei ein Dupplicat, bei sowas bleibt nur ein Ticket offen (meistens das Erste, oder das Bessere) und die Anderen werden als Doppelt markiert und geschlossen.
Blöder Weise kann ich diesmal aber nicht sehen welches das andere Dupplikat ist (das Offene) ... mir war so dass das sonst ebenfalls im Kopf stünde,
aber es könnte sein, dass 10581 das aktuelle Ticket ist.

MEissing und er arbeitet dort sogar, im deutschen Support :wink:

Wang Wang: keine Ahnung, kenn ihn nicht (dachte erst er seit einer der Entwickler, aber wohl doch nicht)


Die Meisten entwickeln für Windows ... dort fällt der Fehler scheinbar nicht auf
und zu Viele schauen leider garnicht erst in QC, bzw. ins neue Quality-Portal.

[TurboMagic]

Ich glaube auch, das Wang Wang Anwender ist.

[QuickAndDirty]

Der Fehler ist in Delphi 10.41 samt aller Patches immernoch in der System.pas....
Und auch die System.DateUtils.Pas benutzt immernoch UTF8ToString für Bytearrays....
Warum gucken die nicht in den Fehlerbericht. Im Prinzip ist die Lösung ja fast mitgeliefert.

[himitsu]

Zitat:

Zitat von QuickAndDirty (Beitrag 1479777)

Im Prinzip ist die Lösung ja fast mitgeliefert.

Das ist zu einfach.
Bei sowas mußt du erst 10 Jahre warten. (vielleicht muß man ja bei Fremdcode vorher die NSA fragen, damit die darin nach bösem russischen Hackercode gucken können)

Vor etwa 10 Jahren hatte ich einen QC erstellt, wo es um ein "Event" für Records geht (erstellen, kopieren/zuweisen und freigeben)
und hatte einen Lösungsvorschlag gleich mitgeliefert (etwa 5 Zeilen Code und zwei/drei Felder in der RTTI des Records).
Jetzt wurde sowas (bissl anders) als nagelneues Feature verkauft ... nennt sich Managed Records. :stupid: