AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Sprachen und Entwicklungsumgebungen Object-Pascal / Delphi-Language D12: NativeInt ( womöglich auch andere ), von "strong alias" zu "weak alias"

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

Ein Thema von Rollo62 · begonnen am 23. Feb 2024 · letzter Beitrag vom 1. Mär 2024
Antwort Antwort
Seite 1 von 2  1 2   
Rollo62

Registriert seit: 15. Mär 2007
3.895 Beiträge
 
Delphi 12 Athens
 
#1

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

  Alt 23. Feb 2024, 09:43
Delphi-Version: 12 Athens
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.

Geändert von Rollo62 (23. Feb 2024 um 09:45 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.089 Beiträge
 
Delphi 12 Athens
 
#2

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

  Alt 23. Feb 2024, 09:51
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)
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (23. Feb 2024 um 15:43 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Stevie
Stevie

Registriert seit: 12. Aug 2003
Ort: Soest
4.008 Beiträge
 
Delphi 10.1 Berlin Enterprise
 
#3

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

  Alt 23. Feb 2024, 15:38
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.
Stefan
“Simplicity, carried to the extreme, becomes elegance.” Jon Franklin

Delphi Sorcery - DSharp - Spring4D - TestInsight
  Mit Zitat antworten Zitat
Rollo62

Registriert seit: 15. Mär 2007
3.895 Beiträge
 
Delphi 12 Athens
 
#4

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

  Alt 23. Feb 2024, 16:28
Vielen Dank für die Tipps.

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.

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.
  Mit Zitat antworten Zitat
Rollo62

Registriert seit: 15. Mär 2007
3.895 Beiträge
 
Delphi 12 Athens
 
#5

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

  Alt 26. Feb 2024, 06:59
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.
  Mit Zitat antworten Zitat
Benutzerbild von dummzeuch
dummzeuch

Registriert seit: 11. Aug 2012
Ort: Essen
1.461 Beiträge
 
Delphi 10.2 Tokyo Professional
 
#6

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

  Alt 26. Feb 2024, 09:31
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.
Thomas Mueller
  Mit Zitat antworten Zitat
Benutzerbild von jaenicke
jaenicke

Registriert seit: 10. Jun 2003
Ort: Berlin
9.321 Beiträge
 
Delphi 11 Alexandria
 
#7

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

  Alt 26. Feb 2024, 10:43
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.
Sebastian Jänicke
Alle eigenen Projekte sind eingestellt, ebenso meine Homepage, Downloadlinks usw. im Forum bleiben aktiv!
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.089 Beiträge
 
Delphi 12 Athens
 
#8

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

  Alt 26. Feb 2024, 11:39
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)
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
Rollo62

Registriert seit: 15. Mär 2007
3.895 Beiträge
 
Delphi 12 Athens
 
#9

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

  Alt 26. Feb 2024, 12:08
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.

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.
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.089 Beiträge
 
Delphi 12 Athens
 
#10

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

  Alt 26. Feb 2024, 12:26
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests

Geändert von himitsu (26. Feb 2024 um 12:31 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 05:03 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz