D12: NativeInt ( womöglich auch andere ), von "strong alias" zu "weak alias"

[Rollo62]

Hallo zusammen,

ich suche gerade nach ein paar mysteriösen, unterschiedlichen Verhalten von Apps unter D12, was vorher einwandfrei lief.
Mir ist die Umstellung siehe oben bekannt, hier unter anderem auch aus den Blogs von Marco Cantu und GDK

Ich hätte da noch ein paar zusammenfassende Fragen, zur Klärung, ich stelle meine Thesen hier mal auf:
1. Umstellung NativeInt zu weak alias: Betrifft das ausschließlich NativeInt/NativeUInt, oder evtl. auch um andere integrierte Typen (ByteBool, WordBool, LongBool, evtl. noch mehr)?
2. Gab es das Konzept "weak alias" auch schon vor D12, für andere Typen? Ich meine nicht.
3. Das Verhalten der NativeInt u.a. ist generell exakt gleich geblieben, bis auf "overloaded" Methoden. So sollte es sein.
4. Die problematischen "overloaded" Methoden etc. sollten als Compiletime-Fehler aufpoppen und müssen manuell bearbeitet werden.
5. Wenn es keine solchen Fehler gibt, dann ist automatisch davon auszugehen, dass NativeInt u.a. richtig arbeitet? Da bin ich nicht sicher.
6. Gibt es andere Konfigurationen/Konstellationen, außer "overload", welche problematisch sind? Die sehe ich nicht.
7. Welche Änderungen der Rtti gibt es bzgl. "weak alias", könnte dies Fehler verursachen? Ich meine, das sollte Rtti eigentlich nicht betreffen.
8. Es gibt es zig. Änderungen der neuen RTL, welche zig. unbekannte Fehler provozieren. Oder kann man die Anzahl der Änderungen überschauen?
9. Welche RTL und andere Bereiche sind als hochkritisch einzustufen (Math, String, Stream, ...)? Ich meine da gibt es keine besondere Priorität.
10. Welche Problematiken sind unter verschiedenen Plattformen zu erwarten? Ich meine, das sollte überall gleich sein.

Vielleicht können mir die Sprachexperten hier beistehen, welche meiner Thesen/Fragen richtig oder falsch sind,
so dass ich besser weiß, von wo die Problematik herrühren könnte.

[himitsu]

Es gibt mehrere BugReports bei Emba, zu diesem Thema.

Viele "Handle" (THandle/HANDLE/HWND/HDC/...) setzen intern auf diesen Typen auf, was somit vor allem auf Casts oder "falsch" Typen eine Wirkung hat.
z.B. wäre es beim SendMessage/PostMessage eigentlich schon immer richtig gewesen WPARAM/LPARAM/LRESULT als Typen zu nutzen, anstatt NativeInt/Integer, was sich jetzt auch in vielen FremdCodes/Fremdkomponenten rächen wird.

Und ganz besonders kommt neu auch noch WinMD das dazu,
denn jetzt, wo es das gibt, wird Emba wohl noch weniger Lust verspüren die Fehler in der eigenen WinAPI zu beheben. (gab/gibt auch hierzu viele BugReports und FeatureRequests, welche oftmals noch unbeantwortet oder einfach nur abgelehnt wurden)
https://www.delphipraxis.net/214473-...vor-winmd.html

Besonders geil ist im WinMD die Tatsache, dass viele Typen neu doppelt/mehrfach deklariert sind und das auch noch unterschiedlich, wie z.B. HANDLE ist einmal ein Signed und drüben Unsigned, was Dank der "strong alias", sowie der neuerdings standardmäßig aktiven Bereichprüfung echt enorm Spaß macht.
(bin inzwischen fast geneigt ein eigenes GetItPackage für WinMD zu erstellen, vor allem da ich seit Wochen Monaten angelaufene Fehler nichmal mehr melden kann)

[Stevie]

Wenn du einen Fehler in Verbindung mit der NativeInt Umstellung in deinem Code suchst würde ich folgendes empfehlen:
Schalte W1071, W1072 und ggf W1073 ein und schaue, wo die anschlagen, das sollte idR die Stellen finden, bei denen z.B. implizit von 64bit auf 32bit truncated wird.

[Rollo62]

Vielen Dank für die Tipps.

Zitat von Stevie:

Wenn du einen Fehler in Verbindung mit der NativeInt Umstellung in deinem Code suchst würde ich folgendes empfehlen:
Schalte W1071, W1072 und ggf W1073 ein und schaue, wo die anschlagen, das sollte idR die Stellen finden, bei denen z.B. implizit von 64bit auf 32bit truncated wird.

Das nach dem Upgrade die Warnings disabled sind, da wäre ich sicher erst als Letztes gekommen.
Wieder ein Eintrag für meine Checkliste vom IDE und Projekt-Setup.

Da drängt sich mir die Frage auf, ob das NativeInt auch entsprechende Pointer oder Typecast Probleme nach sich zieht.
Ist das nicht sehr wahrscheinlich, sind die auch damit abgedeckt?
Vielleicht machen dann die W1048 Unsafe typecast, W1046 Unsafe type und andere auch Sinn, das geht aber gleich in die Tausende.

Zitat von himitsu:

Es gibt mehrere BugReports bei Emba, zu diesem Thema.

Das kann ich mir vorstellen, aber ich hätte die Hoffnung dass es mittlerweile irgendeinen groben Portierungsplan gibt.
Die Tipps von Stefan sind schonmal viel Wert in diese Richtung.

Noch mache ich Tests ohne Patch 1, aber ich denke morgen werde ich direkt auf Patch 1 wechseln, denn es läuft schon ziemlich stabil.
Kann ja nur besser werden.

[Rollo62]

Wenn ich alle Warnings einschalte, was ich liebend gerne so machen würde, kommen auch solche Dinge hoch, z.B. aus Spring.pas:

Delphi-Quellcode:

  Int24 = packed record   //<== unsafe type Int24
  case Integer of
    0: (Low: Word; High: Byte);
    1: (Bytes: array[0..2] of Byte);
  end;

Zitat:

W1046 Unsafe type '%s%s%s' (Delphi)

You have used a data type or operation for which static code analysis cannot prove that it does not overwrite memory. For example, you might receive this warning if you declare something as absolute. Such code can be considered a security risk.

wie gehe ich denn damit um?
Meine Vermutung, dass es einfach an den fehlenden Bytes liegen sollte trifft nicht zu:

Delphi-Quellcode:

  
  Int24 = packed record     //<== Wirft das Warning genauso, obwohl der Record überall 4-Byte sein sollte
  case Integer of
    0: (Low: Word; High, Pinky, Ponky: Byte);
    1: (Bytes: array[0..3] of Byte);
  end;

Ich denke mal, dass man das Warnung an der Stelle einfach abschalten sollte, oder wie würdet ihr das machen?

Delphi-Quellcode:

  {$WARN UNSAFE_TYPE OFF}
  Int24 = packed record
  case Integer of
    0: (Low: Word; High: Byte);
    1: (Bytes: array[0..2] of Byte);
  end;
  {$WARN UNSAFE_TYPE ON}

Das Warning hat aber auch einen Sinn und sollte eigentlich dort kommen, wo es benutzt wird.

[dummzeuch]

Die Unsafe Type warnings schalte ich immer aus. Sie sind ein Überbleibsel aus der Zeit, als Delphi zu dotNET migriert werden sollte und machen bei normalen Programmen wenig Sinn.

[jaenicke]

Zitat von Rollo62:

Wenn ich alle Warnings einschalte, was ich liebend gerne so machen würde, kommen auch solche Dinge hoch, z.B. aus Spring.pas

Was macht es denn für einen Sinn Drittanbieterbibliotheken direkt ins Projekt einzubinden und jedesmal mit zu kompilieren (außer zum Debuggen mal ausnahmsweise)? Wenn du das nicht machst, bekommst du auch nur die Meldungen zu deinen eigenen Quelltexten.

[Stevie]

Zitat von Rollo62:

Das nach dem Upgrade die Warnings disabled sind, da wäre ich sicher erst als Letztes gekommen.

Die waren noch nie enabled.

Zitat von Rollo62:

Wenn ich alle Warnings einschalte, was ich liebend gerne so machen würde, kommen auch solche Dinge hoch, z.B. aus Spring.pas

Du kompilierst Spring mit seinen Settings im Rahmen seiner Packages und nutzt die precompiled dcus und lässt jegliche Bugs in Spring meine Sorge sein.

Zitat von Rollo62:

Hatte ich auch aus, aber laut Stefan macht es ja Sinn, diese für das "weak alias" Problem mal durchzusehen.

Ich habe nichts von den unsafe Type warnings gesagt, die hast du dir in #4 dazugedichtet.

Zitat von Rollo62:

Aktuell ist es so, dass ich ca. 3000 Warnings bekomme aus Delphi-Source, 3rd-Library, in meinem eigenen Code habe ich 0 Warnings.

Jetzt weißt du, warum die Warnings nie aktiviert waren
Ich hab mich letztes Jahr schon daran gesetzt, sie sukzessive abzuarbeiten, aber spätestens, wenn mit bestimmten RTL Funktionen interagiert wird, wird es manchmal hässlich - vor allem vor Delphi 12.
Deshalb ist der Code in Spring noch nicht frei von den von mir oben erwähnten Warnings (evtl hätte ich die in Spring.inc nicht nur auskommentiert lassen sondern explizit ausschalten sollen, so dass es nicht zu dieser Flut an Warnungen kommt, wenn man nicht precompiled.

[Rollo62]

Zitat von Stevie:

Zitat von Rollo62:

Das nach dem Upgrade die Warnings disabled sind, da wäre ich sicher erst als Letztes gekommen.

Die waren noch nie enabled.

Ich hätte schwören können, dass ich die mal aktiviert hatte.
War aber wohl doch was anderes.

Damit habe ich zumindest die Ursache gefunden, bei einem StreamHelper mit überladenen Read/Write Funktionen.
War schwer zu finden den, aber dank dem Tip hat es geklappt.

Ich frage mich, ob man die 3000 anderen Warnings angehen sollte,ist wahrscheinlich kaum zu bewerkstelligen bei z.B. Pointern und anderen Dingen.
Alle Warnungen um die kritischen Stellen abzuschalten macht auch keinen Sinn, weil die Warnung dann weg ist.
Wahrscheinlich ist es das beste einfach mal ab und zu die Warnings einschalten und durchsehen ob was Neues dazugekommen ist.