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.

[himitsu]

Weil Emba das so vor macht?
ja, noch was, das am WinMD bissl nervt, dass die Units nicht vorkompiliert sind/werden (aber dank der vielen Bugs aktuell praktisch, weil man die gleich beheben kann, um erstmal arbeiten zu können, bis in 2 Jahren das QualityPortal wieder läuft und die Bugs behoben sind)

[Rollo62]

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

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

Zitat von jaenicke:

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.

Ja ich weiß, dass man besser vorkompilierte Libraries einsetzen sollte, wegen der Kompilierzeit.
Ich habe mir das aber vor Jahren angewöhnt, als ich genau damit mal extreme Probleme hatte, mit verwaisten alten, neuen Libraries.
Das Kompilieren geht bei mir recht schnell, daher habe ich nicht unbedingt versucht das jetzt umzustellen.
So kann ich aber 100 % ausschließen, dass mir irgendwo alte DCU, insbesondere von Drittanbietern, da reingrätschen,
damit bin ich die letzten Jahre immer gut gefahren.

Trotzdem muss ich mich ja auch fragen, inwieweit so ein Warning auch auf meinen Code Einfluss hat, wenn der in einer 3rd Library auftritt.
Aktuell ist es so, dass ich ca. 3000 Warnings bekomme aus Delphi-Source, 3rd-Library, in meinem eigenen Code habe ich 0 Warnings.
Was sollte ich denn damit machen, einfach wegschalten und vergessen?

Ich suche ja gerade mysteriöse Probleme, die bisher nie auftraten, erst ab D12.
Da finde ich den Tipp mir das mal anzusehen schon sehr gut.

Trotzdem die Frage:
Was macht ihr mit solchen Warnings?
- Einzeln im Code wegschalten ( so muss ich mir die zumindest einzeln ansehen, bein nächsten Update sind aber alle wieder drin )
- Komplett wegschalten (daher komme ich ja, aber das heißt, ich übernehme die 3rd Library ohne Rückfragen als 100% OK )
- Immer drinlassen (Also ständig 3000 Warnings zu sehen sind nicht mein Ding )

Schalte ich im Beispiel das Warning weg, dann KANN es ja beim Aufrufer Probleme machen.
Ich kann aber jetzt auch nicht die ganzen 300 Stellen checken, wo das vielleicht verwendet wird.
Und selbst wenn, was mache ich damit, wann ist ein Aufruf "unsafe"?

Das geht schnell in Sphären, die man nicht mehr handlen kann.

[himitsu]

Nicht nur das Tempo ...
Ohne dass man in den Units überall selbst deaktivieren muß, kann man Fremd-Bibliotheken ohne Debuginfos vorkompilieren, bzw. auch parallel mit Debuginfos (zum leichten umschalten)




Es nervt ja schon, dass jemand es geil fand, dass die DebugDCUs nun standardmäßig in neuen Projekten aktiv sind und Emba sich weigert das wieder rückgängig zu machen.

Wer will denn beim Debuggen des eigenen Codes (meisten) ständig gern in Fremdcodes landen, am Bestens noch im Assembler der System.pas usw.?





Eigentlich wollte ich für ein Projekt die Delphi-Debuginfos in Microsoft-Debuginfos konvertieren,
aber da das auch andersrum geht und ich nun weiß, wo ich Debuginfos der System-DLLs her bekomm, wäre es doch zu geil, wenn man die in Selphi einschleußt und dann nicht mehr nur selphi-eigene Units debuggen muß, sonden auch gleich die vom Windows .... hach, das wird ein Spaß ... einmal aufversehn F7 statt F8/F9 und du bist am Arsch.